Add an InstSimplify for repetitive array expressions
I noticed in https://github.com/rust-lang/rust/pull/135068#issuecomment-2569955426 that GVN's implementation of this same transform was quite profitable on the deep-vector benchmark. But of course GVN doesn't run in unoptimized builds, so this is my attempt to write a version of this transform that benefits the deep-vector case and is fast enough to run in InstSimplify.
The benchmark suite indicates that this is effective.
Use llvm.memset.p0i8.* to initialize all same-bytes arrays
Similar to #43488
debug builds can now handle `0x0101_u16` and other multi-byte scalars that have all the same bytes (instead of special casing just `0`)
Adds `#[rustc_force_inline]` which is similar to always inlining but
reports an error if the inlining was not possible, and which always
attempts to inline annotated items, regardless of optimisation levels.
It can only be applied to free functions to guarantee that the MIR
inliner will be able to resolve calls.
Subtree sync for rustc_codegen_cranelift
This has a couple of changes that will conflict with https://github.com/rust-lang/rust/pull/134338.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
Rollup of 7 pull requests
Successful merges:
- #132607 (Used pthread name functions returning result for FreeBSD and DragonFly)
- #134693 (proc_macro: Use `ToTokens` trait in `quote` macro)
- #134732 (Unify conditional-const error reporting with non-const error reporting)
- #135083 (Do not ICE when encountering predicates from other items in method error reporting)
- #135251 (Only treat plain literal patterns as short)
- #135320 (Fix typo in `#[coroutine]` gating error)
- #135321 (remove more redundant into() conversions)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not ICE when encountering predicates from other items in method error reporting
See the comments I left in the code and the test file.
Fixes https://github.com/rust-lang/rust/issues/124350
Unify conditional-const error reporting with non-const error reporting
This PR unifies the error reporting between `ConditionallyConstCall` and `FnCallNonConst` so that the former will refer to syntactical sugar like operators by their sugared name, rather than calling all operators "methods". We achieve this by making the "non-const" part of the error message generic over the "non" part so we can plug in "conditionally" instead.
This should ensure that as we constify traits in the standard library, we don't regress error messages for things like `==`.
r? fmease or reassign
Remove special-casing for argument patterns in MIR typeck (attempt to fix perf regression of #133858)
See [my comment](https://github.com/rust-lang/rust/pull/133858#issuecomment-2579029618) on #133858 for more information. This is just a guess as to what went wrong, and I haven't been able to get the profiler running locally, so I'll need a perf run to make sure this actually helps.
There's one test's stderr that suffers a bit, but this was just papering over the issue anyway. Making region errors point to the correct constraints in the presence of invariance/contravariance is a broader problem; the current way it's handled is mostly based on guesswork, luck, and hoping it works out. Properly handling that (somehow) would improve the test's stderr without the hack that this PR reverts.
Make sure to walk into nested const blocks in `RegionResolutionVisitor`
Fixes https://github.com/rust-lang/rust/issues/135306
I tried auditing the rest of the visitors that called `.visit_body`, and it seems like this is the only one that was missing it. I wonder if we should modify intravisit (specifcially, that `NestedBodyFilter` stuff) to make this less likely to happen, tho...
r? oli-obk
`-Zrandomize-layout` harder. `Foo<T> != Foo<U>`
Tracking issue: #106764
Previously randomize-layout only used a deterministic shuffle based on the seed stored in an Adt's ReprOptions, meaning that `Foo<T>` and `Foo<U>` were shuffled by the same seed. This change adds a similar seed to each calculated LayoutData so that a struct can be randomized both based on the layout of its fields and its per-type seed.
Primitives start with simple seed derived from some of their properties. Though some types can no longer be distinguished at that point, e.g. usize and u64 will still be treated the same.
previously field ordering was using the same seed for all instances of Foo,
now we pass seed values through the layout tree so that not only
the struct itself affects layout but also its fields
Rollup of 3 pull requests
Successful merges:
- #134898 (Make it easier to run CI jobs locally)
- #135195 (Make `lit_to_mir_constant` and `lit_to_const` infallible)
- #135261 (Account for identity substituted items in symbol mangling)
r? `@ghost`
`@rustbot` modify labels: rollup
Make `lit_to_mir_constant` and `lit_to_const` infallible
My motivation for this change is just that it's annoying to check everywhere, especially since all but one call site was just ICEing on errors anyway right there.
They can still fail, but now just return an error constant instead of having the caller handle the error.
fixes#114317fixes#126182
Rollup of 5 pull requests
Successful merges:
- #135212 (Remove outdated information in the `unreachable_pub` lint description)
- #135225 (Explicitly build proc macro test with panic=unwind)
- #135242 (add missing provenance APIs on NonNull)
- #135247 (Add a list of symbols for stable standard library crates)
- #135269 (Remove some unnecessary `.into()` calls)
r? `@ghost`
`@rustbot` modify labels: rollup
Add a list of symbols for stable standard library crates
There are a few locations where the crate name is checked against an enumerated list of `std`, `core`, `alloc`, and `proc_macro`, or some subset thereof. In most cases when we are looking for any "standard library" crate, all four crates should be treated the same. Change this so the crates are listed in one place, and that list is used wherever a list of `std` crates is needed.
`test` could be considered relevant in some of these cases, but generally treating it separate from the others seems preferable while it is unstable.
There are also a few places that Clippy will be able to use this.
Explicitly build proc macro test with panic=unwind
Fuchsia explicitly builds rust and all rust targets with `-C panic=abort` to minimize code generation size. However, when compiling a proc-macro with this setting it can cause a warning to be emitted, which breaks `tests/ui/invalid-compile-flags/crate-type-flag.rs`. This hasn't been a problem in the past for us since we compile our proc macros on host, rather than inside Fuchsia.
This attempts to fix the issue by explicitly requiring that we're using the unwinder when compiling this test to avoid the warning being emitted.
Fixes#135223
Remove outdated information in the `unreachable_pub` lint description
As far as I understand the `unreachable_pub` lint hasn't had false-positives since it started using "effective visibilities". Let's remove that warning from the lint description.
r? `@petrochenkov`