Rename impl_of_method and trait_of_item
This PR used to tweak the implementation of impl_of_method, but that introduced a perf regression.
Rename impl_of_method and trait_of_item to impl_of_assoc and trait_of_assoc respectively. This reflects how the two functions are closely related. And it reflects the behavior more accurately as the functions check whether the input is an associated item.
Allow more MIR SROA
This removes some guards on SROA that are no longer needed:
- With https://github.com/rust-lang/compiler-team/issues/838 it no longer needs to check for SIMD
- With https://github.com/rust-lang/compiler-team/issues/807 it no longer needs to check for niches
- This means that `Wrapper(char)` and `Pin<&mut T>` can get SRoA'd now, where previously they weren't because the check was banning SRaA for anything with a niche -- not just things with `#[rustc_layout_scalar_valid_range_*]`.
- Technically rust-lang/rust#133652 isn't complete yet, but `NonZero` and `NonNull` have already moved over, so this is fine. At worst this will mean that LLVM gets less `!range` metadata on something that wasn't already fixed by rust-lang/rust#133651 or rust-lang/rust#135236, but that's still sound, and unblocking general SRoA is worth that tradeoff.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs)
- rust-lang/rust#144151 (`tests/ui/issues/`: The Issues Strike Back [1/N])
- rust-lang/rust#144300 (Clippy fixes for miropt-test-tools)
- rust-lang/rust#144399 (Add a ratchet for moving all standard library tests to separate packages)
- rust-lang/rust#144472 (str: Mark unstable `round_char_boundary` feature functions as const)
- rust-lang/rust#144503 (Various refactors to the codegen coordinator code (part 3))
- rust-lang/rust#144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`)
r? `@ghost`
`@rustbot` modify labels: rollup
coverage: Infer `instances_used` from `pgo_func_name_var_map`
In obscure circumstances involving macro-expanded spans, we would sometimes emit a covfun record for a function with no physical coverage counters, and therefore no corresponding entry in the “PGO names” section of the binary. The absence of that name entry causes `llvm-cov` to fail with the cryptic error message:
```text
malformed instrumentation profile data: function name is empty
```
We can eliminate this mismatch by removing `instances_used` entirely, and instead inferring its contents from the keys of `pgo_func_name_var_map`.
This makes it impossible for a "used" function to lack a PGO name entry.
---
This is an attempt to eliminate the cause of rust-lang/rust#141577 when re-landing changes like rust-lang/rust#144298 in the future.
I haven't been able to reproduce the underlying issue in an in-tree test, because the only known repro involves a non-trivial derive proc-macro that relies on `syn` and `proc-macro2`. But I have manually verified in a separate branch that this change would have prevented the reoccurrence of https://github.com/rust-lang/rust/issues/141577#issuecomment-3120667286.
Various refactors to the codegen coordinator code (part 3)
Continuing from https://github.com/rust-lang/rust/pull/144062 this removes an option without any known users, uses the object crate in favor of LLVM for getting the LTO bitcode and improves the coordinator channel handling.
Port the proc macro attributes to the new attribute parsing infrastructure
Ports `#[proc_macro]`, `#[proc_macro_attribute]`, `#[proc_macro_derive]` and `#[rustc_builtin_macro]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971351163
I've split this PR into commits for reviewability, and left some comments to clarify things
I did 4 related attributes in one PR because they share a lot of their code and logic, and doing them separately is kind of annoying as I need to leave both the old and new parsing in place then.
r? ``@oli-obk``
cc ``@jdonszelmann``
Don't special-case llvm.* as nounwind
Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code.
The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.
Closesrust-lang/rust#132416.
`@rustbot` label +T-compiler +A-panic
Avoid unnecessary `new_adt`/`new_fn_def` calls.
They can be skipped if there are no arguments, avoiding the "relate" operation work and also the subsequent interning.
r? `@ghost`
In obscure circumstances, we would sometimes emit a covfun record for a
function with no physical coverage counters, causing `llvm-cov` to fail with
the cryptic error message:
malformed instrumentation profile data: function name is empty
We can eliminate this mismatch by removing `instances_used` entirely, and
instead inferring its contents from the keys of `pgo_func_name_var_map`.
This makes it impossible for a "used" function to lack a PGO name entry.
Unify LLVM ctlz/cttz intrinsic generation
The type signature for `llvm.ctlz` is the same as the one for `llvm.cttz`, which enables a small simplification.
No longer need `alloca`s for consuming `Result<!, i32>` and similar
In optimized builds GVN gets rid of these already, but in `opt-level=0` we actually make `alloca`s for this, which particularly impacts `?`-style things that use actually-only-one-variant types like this.
While doing so, rewrite `LocalAnalyzer::process_place` to be non-recursive, solving a 6+ year old FIXME.
r? codegen
Enable outline-atomics for aarch64-unknown-linux-musl
They were disabled in bd287fa508 and haven't been causing problems for a while anymore, see https://github.com/rust-lang/rust/issues/89626 for details.
The entire testsuite still passes on `aarch64-unknown-linux-musl` with this feature enabled.
Stop compilation early if macro expansion failed
Fixesrust-lang/rust#116180.
So there isn't really a type that is central for macro expansion and some errors are actually emitted (because the resolution happens after the expansion I suppose) after the expansion pass (like "not found macro"). Sometimes, errors are only emitted on the second "try" (to improve error output). So I couldn't reach a similar solution than what was done in https://github.com/rust-lang/rust/pull/133937 and suggested by ````@estebank```` in https://github.com/rust-lang/rust/issues/116180#issuecomment-3109468922. But maybe I missed something?
So in the end, I realized that there is method called every time (except one, described below) a macro error is actually emitted: `ExtCtxt::trace_macros_diag`. Considering I updated what it did, I renamed it into `macro_error_and_trace_macros_diag` to better reflect it.
There is only one call of `trace_macros_diag` which isn't reporting an error but just used for `macro_trace` feature, so I kept it as is.
r? ````@oli-obk````
Let `codegen_transmute_operand` just handle everything
When combined with rust-lang/rust#143720, this means `rvalue_creates_operand` can just return `true` for *every* `Rvalue`. (A future PR could consider removing it, though just letting it optimize out is fine for now.)
It's nicer anyway, IMHO, because it avoids needing the layout checks to be consistent in the two places, and thus is an overall reduction in code. Plus it's a more helpful building block when used in other places this way.
(TBH, it probably would have been better to have it this way the whole time, but I clearly didn't understand `rvalue_creates_operand` when I originally wrote rust-lang/rust#109843.)
Skip walking into param-env component if it has no placeholder/re-var
Although it only provides a minor perf improvement, it seems like it could matter in more pathological cases.
Nobody seems to actually use this, while still adding some extra
complexity to the already rather complex codegen coordinator code.
It is also not supported by any backend other than the LLVM backend.
resolve: Do not create `NameResolutions` on access unless necessary
`fn resolution` now just performs the access, and `fn resolution_or_default` will insert a default entry if the entry is missing.
Allow pretty printing paths with `-Zself-profile-events=args`
`-Zself-profile-events=args` is pretty heavy and can pretty print a lot of stuff. Rather than hunting down specific cases where this happens, I'd just allow calling `trimmed_def_paths` in this mode.
Fixes: https://github.com/rust-lang/rust/issues/144457
r? `@RalfJung`
