Port depgraph testing attributes to parser
Tracking issue: rust-lang/rust#131229
Ports `#[rustc_clean]`, `#[rustc_if_this_changed]` and `#[rustc_then_this_would_need]` attributes.
Removes references to `rustc_dirty` as that attribute was folded into `rustc_clean` some time ago and rename some code accordingly.
r? JonathanBrouwer
Return `ExitCode` from `rustc_driver::main` instead of calling `process::exit`
This makes rustc simply return an exit code from main rather than calling `std::process::exit` with an exit code. This means that drops run normally and the process exits cleanly. This is similar to what happens when an ICE occurs (due to being a panic that's caught by std's `lang_start`).
Also instead of hard coding success and failure codes this uses `ExitCode::SUCCESS` and `ExitCode::FAILURE`, which in turn effectively uses `libc::EXIT_SUCCESS` and `libc::EXIT_FAILURE` (via std). These are `0` and `1` respectively for all currently supported host platforms so it doesn't actually change the exit code.
Use fewer intermediate functions for short backtraces in queries
If we make sure that `compute_fn` in the query's vtable is actually named `__rust_begin_short_backtrace`, we can avoid the need for some additional intermediate functions and stack frames.
This is similar to how the `get_query_incr` and `get_query_non_incr` functions are actually named `__rust_end_short_backtrace`.
---
Before/after comparison: https://github.com/rust-lang/rust/pull/151739#issuecomment-3815432527
---
- Earlier draft of this PR: https://github.com/rust-lang/rust/pull/151719
- Introduction of this backtrace-trimming: https://github.com/rust-lang/rust/pull/108938
compiletest: Don't assume `aux-crate` becomes a `*.so` with `no-prefer-dynamic`
Since it does not make sense to do so. If someone prefers no dynamic stuff, the last thing they want to look for is an .so file. Also add a regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
### Needed by:
- https://github.com/rust-lang/rust/pull/150591 because of https://github.com/rust-lang/rust/issues/151271. But IMHO this PR makes sense on its own.
### Must wait for:
- [x] https://github.com/rust-lang/rust/pull/151695
fN::BITS constants for feature float_bits_const
Also enables the feature for compiler_builtins as otherwise this causes a warning and conflicts with the Float extension trait.
---
Implementation for rust-lang/rust#151073
Feature flag: `#![feature(float_bits_const)]`
Note that this is likely to conflict with some extension traits, as it has with compiler builtins. However, assuming correct values for the constants, they are either `u32`, the same type, which should not cause a problem (as shown by enabling the feature for compiler_builtins), or a different type (e.g. `usize`), which should cause a compiler error. Either way this should never change behaviour unless the extension trait implemented an incorrect value.
Also note that it doesn't seem to be possible to put multiple unstable attributes on an item, so `f128::BITS` and `f16::BITS` are gated behind the feature flags for those primitives, rather than `#![feature(float_bits_const)]`
Since it does not make sense to do so. If someone prefers no dynamic
stuff, the last thing they want to look for is an `.so` file. Also add a
regression test. Without the fix, the test fails with:
error: test compilation failed although it shouldn't!
--- stderr -------------------------------
error: extern location for no_prefer_dynamic_lib does not exist: .../auxiliary/libno_prefer_dynamic_lib.so
--> .../no-prefer-dynamic-means-no-so.rs:9:5
|
LL | no_prefer_dynamic_lib::return_42();
| ^^^^^^^^^^^^^^^^^^^^^
compiletest: Support `--extern` modifiers with `proc-macro` directive
So that the `src/tools/compiletest/src/directives/auxiliary/tests.rs` test does not have to (ab)use the `aux-crate` directive for this purpose.
This is very edge-casey so I don't think we should document this in rustc-dev-guide. Mentioning it will confuse more than it helps. If someone needs to do this they will look at the code and easily find the functionality.
This is a bit hacky since `--extern priv:pm.rs` is not valid, but we can make our directives work however we want. And I think this is a fine pragmatic approach. Doing it "the right way" would be a lot of work for not much gain. Plus, that work can be done incrementally in small steps in the future if wanted.
r? @Zalathar
---
Follow-up to:
- https://github.com/rust-lang/rust/pull/151353
- https://github.com/rust-lang/rust/pull/151670
### Unblocks:
- https://github.com/rust-lang/rust/pull/151691, because without this fix that test fails (see https://github.com/rust-lang/rust/pull/151691#issuecomment-3800315302)
Introducing clap on tidy
### Context
Currently tidy parses paths/flags from args_os manually, and the extraction is spreading multiple files. It may be a breeding ground for bugs.
ref: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/How.20--ci.3Dtrue.20interact.20with.20CiEnv.3F/near/543171560
(N.B. We've talked about introducing a ci flag in tidy in that thread, but I don't do it in this PR as I don't want to put multiple changes into a PR. I will introduce the flag in a coming PR.)
### Changes
This PR replaces current parsing logic with clap. To confirm the new parser works fine, I introduce an unit test for it.
### Build time
We've concerned about how clap increases the build time. In order to confirm the increment is acceptable, I did an experiment on CI:
- Run cargo build without cache for tidy 50 times in each environment on CI
- Calculate an average and a standard deviation from the result, and plot them
Here is the graph:
<img width="943" height="530" alt="rust_tidy_build_time" src="https://github.com/user-attachments/assets/c7deee69-9f38-4044-87dc-76d6e7384f76" />
- Clap tends to increase build time ~2s. We think this is not a big problem
- Build time differs in each environment
- In some cases standard deviation are high, I suppose that busyness of CI instances affect build time
