rustdoc: save target modifiers
`rustdoc` was filling a `target_modifiers` variable, but it was not using the result.
In turn, that means that trying to use a dependency that set a target modifier fails.
For instance, running:
```sh
RUSTC_BOOTSTRAP=1 rustc --edition=2024 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null --emit=metadata -Zfixed-x18 --crate-type rlib --crate-name core $(rustc --print sysroot)/lib/rustlib/src/rust/library/core/src/lib.rs
echo '#![allow(internal_features)]
' | RUSTC_BOOTSTRAP=1 rustdoc --edition=2021 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null -Zfixed-x18 --extern core=libcore.rmeta -
```
will fail with:
```text
error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out`
|
= help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core`
= help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core`
= help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error
```
Thus save the targets modifiers in `Options` to then pass it to the session options, so that eventually the diff can be performed as expected in `report_incompatible_target_modifiers()`.
Cc: ``@azhogin``
Fixes: https://github.com/rust-lang/rust/issues/144521
Remove `compiler-builtins-{no-asm,mangled-names}`
Remove `compiler-builtins-no-asm`
This feature used to be for when Cranelift didn't support inline
assembly, but its last uses were removed in 52933e0bd2 ("Don't disable
inline asm usage in compiler-builtins when the cranelift backend is
enabled"). and cba05a7a14 ("Support naked functions").
This doesn't remove the feature from the `compiler-builtins` crate, that
will be done separately in the subtree repo.
---
Remove `compiler-builtins-mangled-names`
This config was added in 207de019dc ("libary: Forward
compiler-builtins "asm" and "mangled-names" feature") but it does not
appear this has ever been used. The PR adding it (rust-lang/rust#78472) says that
this was exposed to help with configuration and points at the [Hermit
Cargo config], but as far as I can tell, this feature name has never
been mentioned in that repository's git history.
Thus, clean up a seemingly unneeded feature.
[Hermit Cargo config]: ab2b830930/.cargo/config
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``
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`
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.
move uefi test to run-make
Turn the `uefi` test into a more standard `run-make` test, and execute it using the `test-various` CI job like before.
This is just a straightforward translation of the python code, but using `run-make` to supply the target (hence the 3 separate calls in the docker file).
r? ```@jieyouxu```
cc ```@nicholasbishop```
try-job: test-various
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
`rustdoc` was filling a `target_modifiers` variable, but it was not
using the result.
In turn, that means that trying to use a dependency that set a target
modifier fails.
For instance, running:
```sh
RUSTC_BOOTSTRAP=1 rustc --edition=2024 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null --emit=metadata -Zfixed-x18 --crate-type rlib --crate-name core $(rustc --print sysroot)/lib/rustlib/src/rust/library/core/src/lib.rs
echo '#![allow(internal_features)]
' | RUSTC_BOOTSTRAP=1 rustdoc --edition=2021 --target=aarch64-unknown-none-softfloat --sysroot=/dev/null -Zfixed-x18 --extern core=libcore.rmeta -
```
will fail with:
```text
error: mixing `-Zfixed-x18` will cause an ABI mismatch in crate `rust_out`
|
= help: the `-Zfixed-x18` flag modifies the ABI so Rust crates compiled with different values of this flag cannot be used together safely
= note: unset `-Zfixed-x18` in this crate is incompatible with `-Zfixed-x18=` in dependency `core`
= help: set `-Zfixed-x18=` in this crate or unset `-Zfixed-x18` in `core`
= help: if you are sure this will not cause problems, you may use `-Cunsafe-allow-abi-mismatch=fixed-x18` to silence this error
```
Thus save the targets modifiers in `Options` to then pass it to the
session options, so that eventually the diff can be performed as expected
in `report_incompatible_target_modifiers()`.
Fixes: https://github.com/rust-lang/rust/issues/144521
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
clif: Don't set the `compiler-builtins-no-f16-f128` feature
Since rust-lang/rust be35d37d8b ("Use the compiler to determine whether or not to enable f16 and f128"), `compiler-builtins` relies on `rustc` to report whether or not `f16` and `f128` are supported, which is reported by the backend. This means that there should no longer be any need to unconditionally disable the types for clif in Bootstrap.
Backend config: a955f1cd09/compiler/rustc_codegen_cranelift/src/lib.rs (L224-L233)
canonicalize build root in `tests/run-make/linker-warning`
r? jieyouxu
This is similar to rust-lang/rust#139823 -- the test fails for me because my build dir is a symlink.
tests: aarch64-outline-atomics: Remove hardcoded target
Since this test is limited to aarch64 and linux hosts, the `--target` flag is entirely unnecessary and only breaks this on musl hosts. Let the compiler use the default target instead.
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.
library/windows_targets: Fix macro expansion error in 'link' macro
A recent change altered the definition of the link! macro when the windows_raw_dylib feature is enabled, changing its syntax from pub macro {..} to pub macro($tt:tt) {..} in rust-lang/rust#143592
This change introduced a build failure with the error: "macros that expand to items must be delimited with braces or followed by a semicolon".
We add a semicolon to the line causing the issue as we also modify the non windows_raw_dylib link to make use of the link_dylib macro
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````
test using multiple c-variadic ABIs in the same program
tracking issue: https://github.com/rust-lang/rust/issues/100189
Check that multiple c-variadic calling conventions can be used in the same program.
Clang and gcc reject defining functions with a non-default calling convention and a variable
argument list, so C programs that use multiple c-variadic calling conventions are unlikely
to come up. Here we validate that our codegen backends do in fact generate correct code.
(CI will not run this test because it runs on aarch64, I would like to at least test that this runs on windows)
try-job: `x86_64-gnu`
try-job: `x86_64-msvc-*`
try-job: `x86_64-apple-2`
If `HOME` is empty, use the fallback instead
This is a minor change in the `home_dir` api. An empty path is never (or should never be) valid so if the `HOME` environment variable is empty then let's use the fallback instead.
r? libs-api
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.
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#144331 (Disable non_exhaustive_omitted_patterns within matches! macro)
- rust-lang/rust#144376 (Suggest unwrapping when private method name is available in inner type)
- rust-lang/rust#144421 (Call `is_parsed_attribute` rather than keeping track of a list of parsed attributes manually)
- rust-lang/rust#144424 (Allow setting `release-blog-post` label with rustbot)
- rust-lang/rust#144427 (rename ext_tool_checks to extra_checks and use mod.rs)
- rust-lang/rust#144435 (rustc-dev-guide subtree update)
- rust-lang/rust#144448 (Limit defaultness query to impl of trait)
- rust-lang/rust#144462 (Allow pretty printing paths with `-Zself-profile-events=args`)
- rust-lang/rust#144463 (change_tracker: fix a typo)
- rust-lang/rust#144468 (resolve: Do not create `NameResolutions` on access unless necessary)
r? `@ghost`
`@rustbot` modify labels: rollup
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`
Allow setting `release-blog-post` label with rustbot
r? release
I forgot to do this when we originally added the label and updated the generated description for relnotes issues
