Fix formatting command
The formatting command previously had two issues:
- if rustfmt failed, it would print the command invocation. this is unnecessarily noisy
- there was a race condition that lead to orphan rustfmts that would print their output after bootstrap exited
We fix this by
- removing the printing, it's not really useful
- threading failure through properly instead of just yoloing exit(1)
The formatting command previously had two issues:
- if rustfmt failed, it would print the command invocation. this is
unnecessarily noisy
- there was a race condition that lead to orphan rustfmts that would
print their output after bootstrap exited
We fix this by
- removing the printing, it's not really useful
- threading failure through properly instead of just yoloing exit(1)
bootstrap: Overhaul and simplify the `tool_extended!` macro
Similar to #134950, but for the macro that declares build steps for some tools.
The main changes are:
- Removing some functionality that isn't needed by any of the tools currently using the macro
- Moving some code out of the macro and into ordinary helper functions
- Switching to one macro invocation per tool, and struct-like syntax so that rustfmt will format them
There should be no functional change.
The PathSet prefix matching unfortunately also has implications for `./x
build compiler`, because the path filter `"compiler"` gets consumed by
`compile::Rustc` step first after PathSet prefix matching, whereas
before PathSet prefix matching, the later-registered `compile::Assemble`
step would've consumed the `"compiler"` path filter.
This merely papers over the issue with PathSet prefix handling to
unblock contributors for using `./x build compiler`.
Using struct-like syntax allows rustfmt to format macro invocations, instead of
giving up and ignoring them.
Using a separate macro invocation per tool makes the macro slightly simpler,
and isolates syntax errors to individual invocations.
Turn rustc-dev-guide into a Josh subtree
Discussed on [Zulip](https://rust-lang.zulipchat.com/#narrow/channel/196385-t-compiler.2Fwg-rustc-dev-guide/topic/a.20move.20to.20main.20repo.20.28rust-lang.2Frust.29).
Accompanying rustc-dev-guide PR: https://github.com/rust-lang/rustc-dev-guide/pull/2183
I didn't create a bootstrap step for rustc-dev-guide yet, because the rustc-dev-guide version that we currently use in this repo doesn't have linkcheck enabled and that fails tests.
The subtree starts with commit [ad93c5f1c49f2aeb45f7a4954017b1e607df9f5e](ad93c5f1c4).
What I did:
```
export DIR=src/doc/rustc-dev-guide
# Remove submodule
git submodule status ${DIR}
git submodule deinit ${DIR}
git rm -r --cached ${DIR}
rm -rf ${DIR}
# Remove rustc-dev-guide from .gitmodules
git commit -m"Removed `${DIR}` submodule"
# Import history with josh
git fetch https://github.com/rust-lang/rustc-dev-guide ad93c5f1c49f2aeb45f7a4954017b1e607df9f5e
josh-filter ':prefix=src/doc/rustc-dev-guide' FETCH_HEAD
git merge --allow-unrelated FILTERED_HEAD
# A few follow-up cleanup commits
```
r? ehuss
bootstrap: Overhaul and simplify the `tool_check_step!` macro
Main changes:
- Pull most of `run` out of the macro and into a regular helper function
- Reduce the number of redundant/unnecessary macro arguments
- Switch to struct-like syntax so that optional arguments are clearer, and so that rustfmt is happy
~~The one “functional” change is that the `-check.stamp` files now get their name from the final path segment, instead of the struct name; in practice this means that they now contain more hyphens in some cases. As far as I'm aware, the exact filename doesn't matter so this should be fine.~~ (that change has been removed from this PR)
All of the tools that use this macro are currently in-tree, so support for
specifying a `SourceType` was not meaningfully used. It can potentially be
re-added in the future if needed.
bootstrap: Don't apply -Ztls-model=initial-exec to deps of proc-macros
Fixes#134863
1. Checks if a crate name is in a static list before applying the flag
2. Adds a tidy check that gathers transitive deps of proc macros and ensures the list is up to date
cc `@bjorn3` - the issue specifies `rustc_fluent_macro` but I assume this applies to all proc macro crates.
bootstrap: Fix `./x check bootstrap` by moving `shared_helpers::tests`
Running `./x check bootstrap` currently doesn't work, because it builds the bootstrap shim binaries with `cfg(test)`, and those binaries can't find a `tests` submodule when they include `shared_helpers.rs` via `#[path]`.
This PR fixes that by taking the tests module and moving it to `super::tests::shared_helpers_tests` instead.
(The extra `tests` submodule prevents tidy from complaining about unit tests that aren't in a dedicated tests module.)
---
It would be nice to also run `./x check bootstrap compiletest` in CI, so that this and #134848 don't regress, but I didn't want to bundle that change with this fix.
bootstrap: Allow `./x check compiletest`
Did you know that bootstrap didn't support `./x check compiletest`? Well, now it does!
Manually add `"compiletest"` to your `rust-analyzer.check.overrideCommand` check command to get error/warning integration when modifying compiletest.
bootstrap: drop warning for top-level test suite path check due to false positives
The current top-level test suite directory does not exist warning logic doesn't quite handle the more exotic path suffix matches that test filters seem to accept (e.g. `library/test` can be matched with `--exclude test`), so avoid warning on non-existent top-level test suites for now. To avoid false positives, we probably need to query test `Step`s for their `should_run(exclude_filter)` logic.
This retains the fix for the Windows path handling (unlike #134843).
r? `@onur-ozkan`
This doesn't quite handle the more exotic path suffix matches that test
filters seem to accept (e.g. `library/test` can be matched with
`--exclude test`), so avoid warning on non-existent top-level test
suites for now. A proper fix will need to possibly query test `Step`s
for their exclude logic.
