-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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 13 pull requests #130731
Rollup of 13 pull requests #130731
Conversation
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.
I rarely need a debug build of cg_clif, and even if I actually need one, using package overrides in Cargo.toml to only do a debug build for the rustc_codegen_cranelift crate works much better.
To avoid overriding the source for coretests every time.
…ouxu,Amanieu,Jubilee nontemporal_store: make sure that the intrinsic is truly just a hint The `!nontemporal` flag for stores in LLVM *sounds* like it is just a hint, but actually, it is not -- at least on x86, non-temporal stores need very special treatment by the programmer or else the Rust memory model breaks down. LLVM still treats these stores as-if they were normal stores for optimizations, which is [highly dubious](llvm/llvm-project#64521). Let's avoid all that dubiousness by making our own non-temporal stores be truly just a hint, which is possible on some targets (e.g. ARM). On all other targets, non-temporal stores become regular stores. ~~Blocked on rust-lang/stdarch#1541 propagating to the rustc repo, to make sure the `_mm_stream` intrinsics are unaffected by this change.~~ Fixes rust-lang#114582 Cc `@Amanieu` `@workingjubilee`
…ompiler-errors Shrink `TyKind::FnPtr`. By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI. r? `@compiler-errors`
…, r=dtolnay Support `char::encode_utf16` in const scenarios. Relevant tracking issue: rust-lang#130660 The method `char::encode_utf16` should be marked "const" to allow compile-time conversions. This PR additionally rewrites the `encode_utf16_raw` function for better readability whilst also reducing the amount of unsafe code. try-job: x86_64-msvc
…ckh726 No longer mark RTN as incomplete The RFC is accepted and the feature is basically fully implemented. This doesn't mean it's necesarily *ready* for stabiliation; there's probably some diagnostic improvements to be made, and as always, users uncover the most creative bugs. But marking this feature as incomplete no longer serves any purpose, so let's fix that.
…eporting, r=BoxyUwU Don't call `ty::Const::normalize` in error reporting We do this to ensure that trait refs with unevaluated consts have those consts simplified to their evaluated forms. Instead, use `try_normalize_erasing_regions`. **NOTE:** This has the side-effect of erasing regions from all of our trait refs. If this is too much to review or you think it's too opinionated of a diagnostics change, then I could split out the effective change (i.e. erasing regions from this impl suggestion) into another PR and have someone else review it.
…r=Noratrieb Mark `u8::make_ascii_uppercase` and `u8::make_ascii_lowercase` as const. Relevant tracking issue: rust-lang#130698 This PR extends rust-lang#130697 by also marking the `make_ascii_uppercase` and `make_ascii_lowercase` methods in `u8` as const. The `const_char_make_ascii` feature gate is additionally renamed to `const_make_ascii`.
…esolve-const, r=BoxyUwU Introduce `structurally_normalize_const`, use it in `rustc_hir_typeck` Introduces `structurally_normalize_const` to typecking to separate the "eval a const" step from the "try to turn a valtree into a target usize" in HIR typeck, where we may still have infer vars and stuff around. I also changed `check_expr_repeat` to move a double evaluation of a const into a single one. I'll leave inline comments. r? ``@BoxyUwU`` I hesitated to really test this on the new solver where it probably matters for unevaluated consts. If you're worried about the side-effects, I'd be happy to craft some more tests 😄
…al, r=BoxyUwU Replace calls to `ty::Const::{try_}eval` in mir build/pattern analysis We normalize consts in writeback: rust-lang#130645. This means that consts are gonna be as normalized as they're ever gonna get in MIR building and pattern analysis. Therefore we can just use `try_to_target_usize` rather than calling `eval_target_usize`. Regarding the `.expect` calls, I'm not totally certain whether they're correct given rigid unevaluated consts. But this PR shouldn't make *more* ICEs occur; we may have to squash these ICEs when mGCE comes around, tho 😺
…bjorn3 Subtree sync for rustc_codegen_cranelift The main highlight this time is a fix for a miscompilation of RwLock on macOS. Also a Cranelift update and a couple of extra vendor intrinsics on arm64. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
Add test for `available_parallelism()` This is a redo of [this PR](rust-lang#104095). I changed the location of the test as per comments in the original thread. Otherwise the test is practically the same. try-job: test-various
…is-test, r=BoxyUwU tests: Remove spuriously failing vec-tryinto-array codegen test This has failed more than a couple of times now. It costs real time, money, and energy to deal with this, far more than this test is saving us.
@bors r+ rollup=never p=13 |
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message
|
☔ The latest upstream changes (presumably #130724) made this pull request unmergeable. Please resolve the merge conflicts. |
huh. |
Successful merges:
random
feature (alternative version) #129201 (std: implement therandom
feature (alternative version))str
in v0 symbol mangling #130344 (Handle unsized consts with typestr
in v0 symbol mangling)char::encode_utf16
in const scenarios. #130659 (Supportchar::encode_utf16
in const scenarios.)ty::Const::normalize
in error reporting #130712 (Don't callty::Const::normalize
in error reporting)u8::make_ascii_uppercase
andu8::make_ascii_lowercase
as const. #130713 (Marku8::make_ascii_uppercase
andu8::make_ascii_lowercase
as const.)structurally_normalize_const
, use it inrustc_hir_typeck
#130714 (Introducestructurally_normalize_const
, use it inrustc_hir_typeck
)ty::Const::{try_}eval
in mir build/pattern analysis #130715 (Replace calls toty::Const::{try_}eval
in mir build/pattern analysis)available_parallelism()
#130723 (Add test foravailable_parallelism()
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup