We've had a few users get confused when VS Code shows `my_custom_check
--args $saved_file`, as it looks like substitution didn't occur.
Instead, show `my_custom_check --args ...` in the display output. This
is also shorter, and the VS Code status bar generally works best with
short text.
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
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``
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
`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)
tests: debuginfo: Work around or disable broken tests on powerpc
f16 support for PowerPC has issues in LLVM, therefore we need a small workaround to prevent LLVM from emitting symbols that don't exist for PowerPC yet.
It also appears that rust-lang/rust#128973 applies to PowerPC targets as well, though I've only tested 64-bit Linux targets.
rustdoc: add ways of collapsing all impl blocks
either shift+click the Summary button,
or use the `_` key.
this collapses everything,
including (inherent) impl blocks.
no need for a special "expand all impl blocks"
method, as impl blocks are expanded during regular "expand all".
doing "expand all" -> "collapse all" will always
result in only impl blocks being expaned.
not sure the best way to add a GUI test.
fixes https://github.com/rust-lang/rust/issues/134429
