-
Couldn't load subscription status.
- Fork 13.9k
Rollup of 5 pull requests #72065
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 5 pull requests #72065
Conversation
…e target supports it
This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in rust-lang#72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes rust-lang#72006
…tern, r=oli-obk Fix ICE for broken or-pattern in async fn closes rust-lang#71297
Enable `cfg` predicate for `target_feature = "crt-static"` only if the target supports it That's what all other `target_feature`s do.
…kinnison,ollie27 Deprecated emoji Fixes rust-lang#67872. r? @kinnison cc @rust-lang/rustdoc
…-plugin-lto, r=oli-obk Fix disagreeement about CGU reuse and LTO This commit fixes an issue where the codegen backend's selection of LTO disagreed with what the codegen later thought was being done. Discovered in rust-lang#72006 we have a longstanding issue where if `-Clinker-plugin-lto` in optimized mode is compiled incrementally it will always panic on the second compilation. The underlying issue turned out to be that the production of the original artifact determined that LTO should not be done (because it's being postponed to the linker) but the CGU reuse selection thought that LTO was done so it was trying to load pre-LTO artifacts which were never generated. The fix here is to ensure that the logic when generating code which determines what kind of LTO is being done is shared amongst the CGU reuse decision and the backend actually doing LTO. This means that they'll both be in agreement about whether the previous compilation did indeed produce incremental pre-LTO artifacts. Closes rust-lang#72006
…lan-DPC Add missing backtick in E0569 explanation r? @Dylan-DPC
|
@bors r+ p=5 rollup=never |
|
📌 Commit 10e4560 has been approved by |
|
⌛ Testing commit 10e4560 with merge f014b42b23574178671852a1c9c6e909f81483b7... |
|
💔 Test failed - checks-actions |
|
@bors retry |
|
@bors r- |
|
☔ The latest upstream changes (presumably #72020) made this pull request unmergeable. Please resolve the merge conflicts. |
Successful merges:
cfgpredicate fortarget_feature = "crt-static"only if the target supports it #71775 (Enablecfgpredicate fortarget_feature = "crt-static"only if the target supports it)Failed merges:
r? @ghost