Since 122662 this no longer gets used in vtables, so we're safe to fully
drop generating these empty functions. Those are eventually cleaned up
by LLVM, but it's wasteful to produce them in the first place.
This also adds a missing test for fn-ptr casts, which do still need to
generate no-op drop glue. It's possible a future optimization could
point all of those at the same drop glue (e.g., for *mut ()) rather than
for each separate type, but that would require extra work for CFI and
isn't particularly easy to do anyway.
Only traverse reachable blocks in JumpThreading.
Fixes https://github.com/rust-lang/rust/issues/131451
We only compute loop headers for reachable blocks. We shouldn't try to perform an opt on unreachable blocks anyway.
Improve diagnostics for `concat_bytes!` with C string literals
Use the same error as other invalid types for `concat_bytes!`, rather
than using `ConcatCStrLit` from `concat!`. Also add more information
with a note about why this doesn't work, and a suggestion to use a
null-terminated byte string instead.
Rename `LayoutS` to `LayoutData` in comments
`LayoutS` was renamed to `LayoutData`, but some comments in the compiler were not changed. This updates comments in the compiler (and one section of commented-out code in rust-analyzer) to refer to `LayoutData` instead of `LayoutS`.
cc <https://github.com/rust-lang/rust/pull/132252>, `@workingjubilee`
Add diagnostic items for Clippy
Clippy still uses some paths to access items from the standard library. Adding the missing diagnostic items allows removing the last remaining paths.
Closesrust-lang/rust-clippy#5393
error on calls to ABIs that cannot be called
We recently added `extern "custom"`, which cannot be called using a rust call expression. But there are more ABIs that can't be called in that way, because the call does not semantically make sense.
More details are in https://github.com/rust-lang/rust/issues/140566#issuecomment-2846205457
r? `@workingjubilee`
try-job: x86_64-gnu-llvm-19-3
Adjust `with_generic_param_rib`.
Currently all of its call sites construct a `LifetimeRibKind::Generics` value, which `with_generic_param_rib` then deconstructs (and panics if it's a different `LifetimeRibKind` variant).
This commit makes the code simpler and shorter: the call sites just pass in the three values and `with_generic_param_rib` constructs the `LifetimeRibKind::Generics` value from them.
r? `@petrochenkov`
Reason about borrowed classes in CopyProp.
Fixes https://github.com/rust-lang/rust/issues/141122
The current implementation of `CopyProp` avoids unifying two borrowed locals, as this would change the result of address comparison.
However, the implementation was inconsistent with the general algorithm, which identifies equivalence classes of locals and then replaces all locals by a single representative of their equivalence class.
This PR fixes it by forbidding the unification of two *classes* if any of those contain a borrowed local.
Marks ADT live if it appears in pattern
Marks ADT live if it appears in pattern, it implies the construction of the ADT.
1. Then we can detect unused private ADTs impl `Default`, without special logics for `Default` and other std traits.
2. We can also remove `rustc_trivial_field_reads` on `Default`, and the logic in `should_ignore_item` (introduced by rust-lang/rust#126302).
Fixesrust-lang/rust#120770
Extracted from rust-lang/rust#128637.
r? `@petrochenkov`
Insert parentheses around binary operation with attribute
Fixes the bug found by `@fmease` in https://github.com/rust-lang/rust/pull/134661#pullrequestreview-2538983253.
Previously, `-Zunpretty=expanded` would expand this program as follows:
```rust
#![feature(stmt_expr_attributes)]
#![allow(unused_attributes)]
macro_rules! group {
($e:expr) => {
$e
};
}
macro_rules! extra {
($e:expr) => {
#[allow()] $e
};
}
fn main() {
let _ = #[allow()] 1 + 1;
let _ = group!(#[allow()] 1) + 1;
let _ = 1 + group!(#[allow()] 1);
let _ = extra!({ 0 }) + 1;
let _ = extra!({ 0 } + 1);
}
```
```console
let _ = #[allow()] 1 + 1;
let _ = #[allow()] 1 + 1;
let _ = 1 + #[allow()] 1;
let _ = #[allow()] { 0 } + 1;
let _ = #[allow()] { 0 } + 1;
```
The first 4 statements are the correct expansion, but the last one is not. The attribute is supposed to apply to the entire binary operation, not only to the left operand.
After this PR, the 5th statement will expand to:
```console
let _ = #[allow()] ({ 0 } + 1);
```
In the future, as some subset of `stmt_expr_attributes` approaches stabilization, it is possible that we will need to do parenthesization for a number of additional cases depending on the outcome of https://github.com/rust-lang/rust/issues/127436. But for now, at least this PR makes the pretty-printer align with the current behavior of the parser.
r? fmease
correct template for `#[align]` attribute
Tracking issue: https://github.com/rust-lang/rust/issues/82232
related: https://github.com/rust-lang/rust/pull/142507
I didn't fully understand what `template!` did, clearly. An empty `#[align]` attribute was still rejected later, but without this change it does get suggested in certain cases.
I've also updated some outdated references to `#[repr(align)]` on functions.
r? ``@jdonszelmann``
mbe: Refactor transcription
Introduce `MacroTcbCtx` that holds everything relevant to transcription. This allows for the following changes:
* Split `transcribe_sequence` and `transcribe_metavar` out of the heavily nested `transcribe`
* Split `metavar_expr_concat` out of `transcribe_metavar_expr`
This is a nonfunctional change.
Refactor Translator
My main motivation was to simplify the usage of `SilentEmitter` for users like rustfmt. A few refactoring opportunities arose along the way.
* Replace `Translate` trait with `Translator` struct
* Replace `Emitter: Translate` with `Emitter::translator`
* Split `SilentEmitter` into `FatalOnlyEmitter` and `SilentEmitter`
Reduce uses of `hir_crate`.
I tried rebasing my old incremental-HIR branch. This is a by-product, which is required if we want to get rid of `hir_crate` entirely.
The second commit is a drive-by cleanup. It can be pulled into its own PR.
r? ````@oli-obk````
Extract some shared code from codegen backend target feature handling
There's a bunch of code duplication between the GCC and LLVM backends in target feature handling. This moves that into new shared helper functions in `rustc_codegen_ssa`.
The first two commits should be purely refactoring. I am fairly sure the LLVM-side behavior stays the same; if the GCC side deliberately diverges from this then I may have missed that. I did account for one divergence, which I do not know is deliberate or not: GCC does not seem to use the `-Ctarget-feature` flag to populate `cfg(target_feature)`. That seems odd, since the `-Ctarget-feature` flag is used to populate the return value of `global_gcc_features` which controls the target features actually used by GCC. ``@GuillaumeGomez`` ``@antoyo`` is there a reason `target_config` ignores `-Ctarget-feature` but `global_gcc_features` does not? The second commit also cleans up a bunch of unneeded complexity added in https://github.com/rust-lang/rust/pull/135927.
The third commit extracts some shared logic out of the functions that populate `cfg(target_feature)` and the backend target feature set, respectively. This one actually has some slight functional changes:
- Before, with `-Ctarget-feature=-feat`, if there is some other feature `x` that implies `feat` we would *not* add `-x` to the backend target feature set. Now, we do. This fixesrust-lang/rust#134792.
- The logic that removes `x` from `cfg(target_feature)` in this case also changed a bit, avoiding a large number of calls to the (uncached) `sess.target.implied_target_features` (if there were a large number of positive features listed before a negative feature) but instead constructing a full inverse implication map when encountering the first negative feature. Ideally this would be done with queries but the backend target feature logic runs before `tcx` so we can't use that...
- Previously, if feature "a" implied "b" and "b" was unstable, then using `-Ctarget-feature=+a` would also emit a warning about `b`. I had to remove this since when accounting for negative implications, this emits a ton of warnings in a bunch of existing tests... I assume this was unintentional anyway.
The fourth commit increases consistency of the GCC backend with the LLVM backend.
The last commit does some further cleanup:
- Get rid of RUSTC_SPECIAL_FEATURES. It was only needed for s390x "backchain", but since LLVM 19 that is always a regular target feature so we don't need this hack any more. The hack also has various unintended side-effects so we don't want to keep it. Fixes https://github.com/rust-lang/rust/issues/142412.
- Move RUSTC_SPECIFIC_FEATURES handling into the shared parse_rust_feature_flag helper so all consumers of `-Ctarget-feature` that only care about actual target features (and not "crt-static") have it. Previously, we actually set `cfg(target_feature = "crt-static")` twice: once in the backend target feature logic, and once specifically for that one feature. IIUC, some targets are meant to ignore `-Ctarget-feature=+crt-static`, it seems like before this PR that flag still incorrectly enabled `cfg(target_feature = "crt-static")` (but I didn't test this).
- Move fixed_x18 handling together with retpoline handling.
- Forbid setting fixed_x18 as a regular target feature, even unstably. It must be set via the `-Z` flag.
``@bjorn3`` I did not touch the cranelift backend here, since AFAIK it doesn't really support target features. But if you ever do, please use the new helpers. :)
Cc ``@workingjubilee``
rewrite `optimize` attribute to use new attribute parsing infrastructure
r? ```@oli-obk```
I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :)
Waiting on #138165 first
