Rollup of 8 pull requests #121345
Merged
Rollup of 8 pull requests #121345
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 35dad14. Fixes rust-lang#121289
This profile originally made sense when download-ci-llvm = if-unchanged didn't exist and we had the bad tradeoff of "never modify or always compile". Thankfully, these grim times are over and we have discovered clean water, so the only differentiator between the two profiles is the codegen profile having LLVM assertions. Adding them doesn't cause that much of a slowdown, <10% on UI tests from an unscientific benchmark. It also had LLVM warnings when compiling, which makes sense for every compiler contributor brave enough to compile LLVM. The way I removed is by just issueing a nice error message. Given that everyone with this profile should be a contributor and not someone like a distro who is more upset when things break, this should be fine. If it isn't, we can always fall back to just letting codegen mean compiler.
…sertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions`: 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]`) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)!
It is a clearer name because it communicates what the lint does instead of the underlying mechanism it uses (const propagation).
resolve: Scale back unloading of speculatively loaded crates Fixes rust-lang#120830 and fixes rust-lang#120909 while still unblocking rust-lang#117772. I cannot reproduce https://github.com/parasyte/crash-rustc as an UI test for some reason, but I tested all the cases linked above manually.
…aethlin Always inline check in `assert_unsafe_precondition` with cfg(debug_assertions) The current complexities in `assert_unsafe_precondition` are delicately balancing several concerns, among them compile times for the cases where there are no debug assertions. This comes at a large runtime cost when the assertions are enabled, making the debug assertion compiler a lot slower, which is very annoying. To avoid this, we always inline the check when building with debug assertions. Numbers (compiling stage1 library after touching core): - master: 80s - just adding `#[inline(always)]` to the `cfg(bootstrap)` `debug_assertions` (equivalent to a bootstrap bump (uhh, i just realized that i was on a slightly outdated master so this bump might have happened already), (rust-lang#121112)): 67s - this: 54s So this seems like a good solution. I think we can still get the same run-time perf improvements for other users too by massaging this code further (see my other PR about adding `#[rustc_no_mir_inline]` rust-lang#121114) but this is a simpler step that solves the imminent problem of "holy shit my rustc is sooo slow". Funny consequence: This now means compiling the standard library with dbeug assertions makes it faster (than without, when using debug assertions downstream)! r? ```@saethlin``` (or anyone else if someone wants to review this) fixes rust-lang#121110, supposedly
…s, r=dtolnay Implement `NonZero` traits generically. Tracking issue: rust-lang#120257 r? ````@dtolnay````
…y789 Remove the "codegen" profile from bootstrap This profile originally made sense when download-ci-llvm = if-unchanged didn't exist and we had the bad tradeoff of "never modify or always compile". Thankfully, these grim times are over and we have discovered clean water, so the only differentiator between the two profiles is the codegen profile having LLVM assertions. Adding them doesn't cause that much of a slowdown, <10% on UI tests from an unscientific benchmark. It also had LLVM warnings when compiling, which makes sense for every compiler contributor brave enough to compile LLVM. The way I removed is by just issueing a nice error message. Given that everyone with this profile should be a contributor and not someone like a distro who is more upset when things break, this should be fine. If it isn't, we can always fall back to just letting codegen mean compiler.
…-obk Rename `ConstPropLint` to `KnownPanicsLint` `OverflowLint` is a clearer name because it communicates what the lint does instead of the underlying mechanism it uses (const propagation) which should be of secondary concern. `OverflowLint` isn't the most accurate name because the lint looks for other errors as well such as division by zero not just overflows, but I couldn't think of another equally succinct name. As a part of this change. I've also added/updated some of the comments. cc ```@RalfJung``` ```@oli-obk``` for visibility in case you go looking for the lint using the old name. Edit: Changed the name from `OverflowLint` to `KnownPanicsLint`
…strieb target: Revert default to the medium code model on LoongArch targets This reverts commit 35dad14. Fixes rust-lang#121289
Remove `RefMutL` hack in `proc_macro::bridge` From what I can tell, rust-lang#52812 is now fixed, so there is no longer any need to keep this hack around.
…safe_code, r=Nilstrieb Trigger `unsafe_code` lint on invocations of `global_asm` `unsafe_code` already warns about things that don't involve the `unsafe` keyword, e.g. `#[no_mangle]`. This makes it warn on `core::arch::global_asm` too. Fixes rust-lang#103078
rustbot
added
A-meta
|
@bors r+ rollup=never p=8 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: 2b43e75c98 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Feb 20, 2024
|
Finished benchmarking commit (bb59453): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Bootstrap: 641.255s -> 639.883s (-0.21%) |
|
@rust-timer build a405cc6 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (a405cc6): comparison URL. Overall result: no relevant changes - no action neededInstruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 641.255s -> 641.548s (0.05%) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
assert_unsafe_preconditionwith cfg(debug_assertions) #121196 (Always inline check inassert_unsafe_preconditionwith cfg(debug_assertions))NonZerotraits generically. #121241 (ImplementNonZerotraits generically.)ConstPropLinttoKnownPanicsLint#121286 (RenameConstPropLinttoKnownPanicsLint)RefMutLhack inproc_macro::bridge#121302 (RemoveRefMutLhack inproc_macro::bridge)unsafe_codelint on invocations ofglobal_asm#121318 (Triggerunsafe_codelint on invocations ofglobal_asm)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup