tests: Don't check for self-printed output in std-backtrace.rs test
The `Display` implementation for `Backtrace` used to print
stack backtrace:
but that print was since removed. See https://github.com/rust-lang/backtrace-rs/pull/286 and https://github.com/rust-lang/rust/pull/69042. To make the existing test pass, the print was added to the test instead. But it doesn't make sense to check for something that the test itself does since that will not detect any regressions in the implementation of `Backtrace`.
What the test _should_ check is that "stack backtrace:" is _not_ printed in `Display` of `Backtrace`. So do that instead.
This is one small steps towards resolving https://github.com/rust-lang/rust/issues/71706. The next steps after this step involves extending and hardening that test further.
Various refactors to the LTO handling code (part 2)
Continuing from https://github.com/rust-lang/rust/pull/143388 this removes a bit of dead code and moves the LTO symbol export calculation from individual backends to cg_ssa.
We lost the following comment during refactorings:
The current code for niche-filling relies on variant indices instead of actual discriminants, so enums with explicit discriminants (RFC 2363) would misbehave.
Enforce that PR CI jobs are a subset of Auto CI jobs modulo carve-outs
### Background
Currently, it is possible for a PR with red PR-only CI to pass Auto CI, then all subsequent PR CI runs will be red until that is fixed, even in completely unrelated PRs. For instance, this happened with PR-CI-only Spellcheck (rust-lang/rust#144183).
See more discussions at [#t-infra > Spellcheck workflow now fails on all PRs (tree bad?)](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Spellcheck.20workflow.20now.20fails.20on.20all.20PRs.20.28tree.20bad.3F.29/with/529769404).
### CI invariant: PR CI jobs are a subset of Auto CI jobs modulo carve-outs
To prevent red PR CI in completely unrelated subsequent PRs and PR CI runs, we need to maintain an invariant that **PR CI jobs are a subset of Auto CI jobs modulo carve-outs**.
This is **not** a "strict" subset relationship: some jobs necessarily have to differ under PR CI and Auto CI environments, at least in the current setup. Still, we can try to enforce a weaker "subset modulo carve-outs" relationship between CI jobs and their corresponding Auto jobs. For instance:
- `x86_64-gnu-tools` will have `auto`-only env vars like `DEPLOY_TOOLSTATES_JSON: toolstates-linux.json`.
- `tidy` will want to `continue_on_error: true` in PR CI to allow for more "useful" compilation errors to also be reported, whereas it should be `continue_on_error: false` in Auto CI to prevent wasting Auto CI resources.
The **carve-outs** are:
1. `env` variables.
2. `continue_on_error`.
We enforce this invariant through `citool`, so only affects job definitions that are handled by `citool`. Notably, this is not sufficient *alone* to address the CI-only Spellcheck issue (rust-lang/rust#144183). To carry out this enforcement, we modify `citool` to auto-register PR jobs as Auto jobs with `continue_on_error` overridden to `false` **unless** there's an overriding Auto job for the PR job of the same name that only differs by the permitted **carve-outs**.
### Addressing the Spellcheck PR-only CI issue
Note that Spellcheck currently does not go through `citool` or `bootstrap`, and is its own GitHub Actions workflow. To actually address the PR-CI-only Spellcheck issue (rust-lang/rust#144183), and carry out the subset-modulo-carve-outs enforcement universally, this PR additionally **removes the current Spellcheck implementation** (a separate GitHub Actions Workflow). That is incompatible with Homu unless we do some hacks in the main CI workflow.
This effectively partially reverts rust-lang/rust#134006 (the separate workflow part, not the tidy extra checks component), but is not prejudice against relanding the `typos`-based spellcheck in another implementation that goes through the usual bootstrap CI workflow so that it does work with Homu. The `typos`-based spellcheck seems to have a good false-positive rate.
Closesrust-lang/rust#144183.
---
r? infra-ci
Implement AST visitors using a derive macro.
AST visitors are large and error-prone beasts. This PR attempts to write them using a derive macro.
The design uses three traits: `Visitor`, `Visitable`, `Walkable`.
- `Visitor` is the trait implemented by downstream crates, it lists `visit_stuff` methods, which call `Walkable::walk_ref` by default;
- `Walkable` is derived using the macro, the generated `walk_ref` method calls `Visitable::visit` on each component;
- `Visitable` is implemented by `common_visitor_and_walkers` macro, to call the proper `Visitor::visit_stuff` method if it exists, to call `Walkable::walk_ref` if there is none.
I agree this is quite a lot of spaghetti macros. I'm open to suggestions on how to reduce the amount of boilerplate code.
If this PR is accepted, I believe the same design can be used for the HIR visitor.
flt2dec: replace for loop by iter_mut
Perf is explored in https://github.com/rust-lang/rust/issues/144118, which initially showed small losses, but then also showed significant gains. Both are real, but given the smallness of the losses, this seems a good change.
opt-dist: make `artifact-dir` an absolute path for `opt-dist local`
...like for CI environments. the same logic applied as for `build_dir`. fixes the issue where some intermediate steps fail due to path being relative to an active directory
r? Kobzol
try-job: dist-x86_64-msvc
try-job: dist-x86_64-linux
Don't use another main test file as auxiliary
In this case, the exact extern crate isn't very important, it just needs to not be another main test file.
This is part of the changes needed to address the spurious failures from a main test `../removing-extern-crate.rs` being both an auxiliary and a main test file, causing fs races due to multiple `rustc` processes in multiple test threads trying to build the main test file both as a main test and also as an auxiliary at around the same time.
Part 1 of rust-lang/rust#144237.
r? ``@RalfJung`` (or compiler)
clippy: make tests work in stage 1
This finally fixes https://github.com/rust-lang/rust/issues/78717 :)
Similar to what Miri already does, the clippy test step needs to carefully consider which compiler is used to build clippy and which compiler is linked into clippy (and thus must be used to build the test dependencies). On top of that we have some extra complications that Miri avoided by using `cargo-miri` for building its test dependencies: we need cargo to use the right rustc and the right sysroot, but https://github.com/rust-lang/cargo/issues/4423 makes this quite hard to do. See the long comment in `src/tools/clippy/tests/compile-test.rs` for details.
Some clippy tests tried to import rustc crates; that fundamentally requires a full bootstrap loop so it cannot work in stage 1. I had to kind of guess what those tests were doing so I don't know if my changes there make any sense.
Cc ```@flip1995``` ```@Kobzol```
