Feature gating *declarations* => new crate `rustc_feature`
This PR moves the data-oriented parts of feature gating into its own crate, `rustc_feature`.
The parts consist of some data types as well as `accepted`, `active`, `removed`, and `builtin_attrs`.
Feature gate checking itself remains in `syntax::feature_gate::check`. The parts which define how to emit feature gate errors could probably be moved to `rustc_errors` or to the new `rustc_session` crate introduced in #66878. The visitor itself could probably be moved as a pass in `rustc_passes` depending on how the dependency edges work out.
The PR also contains some drive-by cleanup of feature gate checking. As such, the PR probably best read commit-by-commit.
r? @oli-obk
cc @petrochenkov
cc @Mark-Simulacrum
The construction of the GlobalCtxt is moved from a generator's stack to
the Queries struct. Since the GlobalCtxt requires the HIR Forest and the
arenas to live longer, those are moved into Queries the same way.
The resulting handling of objects is more brittle, because consumers of
the Once objects need to be careful of their initialisation.
Add a callback that allows compiler consumers to override queries.
This pull request adds an additional callback that allows compiler consumers such as Prusti and MIRAI to override queries. My hope is that in this way it will be possible to get access to the internal compiler information (e.g. borrow checker) without major changes to the compiler.
This pull request is work in progress because I am still testing if I can get the information which I need.
cc @nikomatsakis
r? @oli-obk
Lockless LintStore
This removes mutability from the lint store after registration. Each commit stands alone, for the most part, though they don't make sense out of sequence.
The intent here is to move LintStore to a more parallel-friendly architecture, although also just a cleaner one from an implementation perspective. Specifically, this has the following changes:
* We no longer implicitly register lints when registering lint passes
* For the most part this means that registration calls now likely want to call something like:
`lint_store.register_lints(&Pass::get_lints())` as well as `register_*_pass`.
* In theory this is a simplification as it's much easier for folks to just register lints and then have passes that implement whichever lint however they want, rather than necessarily tying passes to lints.
* Lint passes still have a list of associated lints, but a followup PR could plausibly change that
* This list must be known for a given pass type, not instance, i.e., `fn get_lints()` is the signature instead of `fn get_lints(&self)` as before.
* We do not store pass objects, instead storing constructor functions. This means we always get new passes when running lints (this happens approximately once though for a given compiler session, so no behavior change is expected).
* Registration API is _much_ simpler: generally all functions are just taking `Fn() -> PassObject` rather than several different `bool`s.
rustdoc: forward -Z options to rustc
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
Move to using Box<dyn Fn() -> ...> so that we can let plugins register
state.
This also adds a callback that'll get called from plugin registration so
that Clippy and other tools can register lints without using the plugin
API. The plugin API still works, but this new API is more compatible
with drivers other than rustc.
Enhance report-time option
## Short overview
This PR is a follow-up to a previously closed#64714 PR.
## Changes introduced by this PR
* `libtest` now retrieves the type of the test within `TestDesc` (available types are: `UnitTest`, `IntegrationTest`, `DocTest`, `Unknown`).
* `--report-time` subcommand of the `libtest` now supports colored output (disabled by default).
* Colorized output depends on the threshold values. Default values (proposed by @wesleywiser):
- For unit-tests: 50ms warn/100ms critical,
- For integration-tests: 500ms warn/1000ms critical,
- For doctests: same as for integration tests,
- For unknown tests: `TEST_WARN_TIMEOUT_S` warn/ `TEST_WARN_TIMEOUT_S * 2` critical (it will only applied single-threaded mode, because otherwise test will be interrupted after reaching `TEST_WARN_TIMEOUT_S`).
- These values can be overrided by setting environment variables (since those thresholds are somewhat constant for every project, it's more flexible to use environment variables than command line arguments).
* New optional flag `--ensure-test-time` for `libtest`. With this flag applied, exectuion time limit excesss will cause test failure.
## What have not been done
There was a comment that it would be nice to have an entry in the Cargo book about it.
However, changes introduced by this PR (and #64663 in which `report-time` flag was added) aren't related directly to `cargo`, it's more about `libtest` itself.
I'm considering that [The Unstable Book](https://doc.rust-lang.org/unstable-book/) is more appropriate place, but not sure if I'm right (and if so, how exactly it should be described).
As one possible option, this PR may be merged without denoting it in the documentation, and in the next PR adding support of this feature to the `cargo` itself, I'll add a note in the Cargo book.
## Scope of this PR
Logical scope of this PR is `libtest` only. However, to get test types, I had to modify also `libsyntax_ext` and `librustdoc` for them to provide information about test type.
## Rationale
Rationale for colored output was submitted in #64714
Providing the information about kind of test was also proposed in #64714, and as an additional benefit this information may be useful for the tools using `libtest` (e.g. `cargo`).
Adding flag to treat time limits excess seems logical to me, so projects that do care about test execution time won't have to invent a wheel.
## Backward compatibility
All the changes are completely backward compatible.
## Demo
r? @wesleywiser
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
rustdoc: change doctests locating rustc binary
We previously used the "naive" approach of replacing the `current_exe()`'s file name with rustc, but now load from the sysroot by default (`$sysroot/bin/rustc`). The functionality of locating the sysroot overlaps/is the same as the functionality used by codegen backend loading; this ensures that any failure cases we've introduced are not exceeding those, and that improvements to finding the sysroot for loading codegen backends likewise enhance rustdoc.
The second commit adds an unstable `--test-builder` flag to rustdoc, and is largely separate (I can split into separate PR, but it's a simple and related change). This is largely intended for "advanced" users at this point (I'm not sure if we'll ever stabilize it); it permits use of a different rustc binary for rustdoc compilation of doctests than the rustdoc binary used when loading. Note, that this may not be what you want as the parsers and such differ (and rustdoc uses its own libsyntax, etc.). However, I've been told that running doctests in miri may be assisted by this change, so I've implemented it; I'll file a tracking issue for it if there's interest in it (and we land this PR).
Avoid more `Symbol`-to-string operations
These commits avoid various `Symbol`-to-string conversions, by doing more operations directly on `Symbol`s. This requires adding a few more static `Symbol`s to the binary.
r? @petrochenkov
This ensures that the failure cases for finding the codegen backend and
for finding the rustc binary are essentially the same, and since we
almost always will load the codegen backend, this is essentially meaning
that the rustc change is not a regression.
Allow cross-compiling doctests
This PR allows doctest to receive a --runtool argument, as well as possibly many --runtool-arg arguments, which are then used to run cross compiled doctests.
Also, functionality has been added to rustdoc to allow it to skip testing doctests on a per-target basis, in the same way that compiletest does it. For example, tagging the doctest with "ignore-sgx" disables testing on any targets that contain "sgx". A plain "ignore" still skips testing on all targets.
See [here](https://github.com/rust-lang/cargo/pull/6892) for the companion PR in the cargo project that extends functionality in Cargo so that it passes the appropriate parameters to rustdoc when cross compiling and testing doctests.
Part of [#6460](https://github.com/rust-lang/cargo/issues/6460)
They are only used by rustc_lexer, and are not needed elsewhere.
So we move the relevant definitions into rustc_lexer (while the actual
unicode data comes from the unicode-xid crate) and make the rest of
the compiler use it.
remove the unstable rustdoc parameter --linker
use the code generation parameter -Clinker (same parameter as rustc)
to control what linker to use for building the rustdoc test executables.
closes: #63816
use the code generation parameter -Clinker (same parameter as rustc)
to control what linker to use for building the rustdoc test executables.
closes: #63816
as the test is small we do not want split up in multiple codegen units
and also as there is multiple test running at the same time this
will reduce the number of concurrent threads
