Retire hir::*ItemRef.
This information was kept for various places that iterate on HIR to know about trait-items and impl-items.
This PR replaces them by uses of the `associated_items` query that contain pretty much the same information.
This shortens many spans to just `def_span`, which can be easier to read.
clippy: fix test filtering when TESTNAME is empty
Fixes https://github.com/rust-lang/rust/issues/143824. Turns out bootstrap was just fine, the TESTNAME logic in clippy was wrong... I still made this a rustc PR as that's where I did all the debugging.
The bootstrap change is not really related, but it's comment-only so not worth a separate PR... adding the `test_args` is also part of what `prepare_cargo_test` would usually do so let's group the code properly.
interpret/allocation: expose init + write_wildcards on a range
Part of https://github.com/rust-lang/miri/pull/4456, so that we can mark down when a foreign access to our memory happened. Should this also move `prepare_for_native_access()` itself into Miri, given that everything there can be implemented on Miri's side?
r? `````@RalfJung`````
Rollup of 12 pull requests
Successful merges:
- rust-lang/rust#143776 (std: move NuttX to use arc4random for random number generation)
- rust-lang/rust#143778 (Some const_trait_impl test cleanups)
- rust-lang/rust#143782 (Disambiguate between rustc vs std having debug assertions in `run-make-support` and `run-make` tests)
- rust-lang/rust#143791 (Update sysinfo version to `0.36.0`)
- rust-lang/rust#143796 (Fix ICE for parsed attributes with longer path not handled by CheckAttribute)
- rust-lang/rust#143798 (Remove format short command trait)
- rust-lang/rust#143803 (New tracking issues for const_ops and const_cmp)
- rust-lang/rust#143814 (htmldocck: better error messages for some negative directives)
- rust-lang/rust#143817 (Access `wasi_sdk_path` instead of reading environment variable in bootstrap)
- rust-lang/rust#143822 (./x test miri: fix cleaning the miri_ui directory)
- rust-lang/rust#143823 ([COMPILETEST-UNTANGLE 5/N] Test mode adjustments and other assorted cleanups)
- rust-lang/rust#143841 (Label clippy changes with `T-clippy`)
Failed merges:
- rust-lang/rust#143850 (Compiletest: Simplify {Html,Json}DocCk directive handling)
r? `@ghost`
`@rustbot` modify labels: rollup
[COMPILETEST-UNTANGLE 5/N] Test mode adjustments and other assorted cleanups
This is part of a patch series to untangle `compiletest` to hopefully nudge it towards being more maintainable.
This PR should contain no functional changes modulo the removed debugger version warning.
- Commit 1: Removes a very outdated debugger version warning.
- Commit 2: Moves `string_enum` out of `common` into `util` module.
- Commit 3: Remove `#[derive(Default)` for `Mode` and `Config`. It is very important for correctness that we *don't* `#[derive(Default)]`, because there are no sensible defaults, so stop pretending there is.
- Commit 4: Rename `Mode` -> `TestMode`, because I would like to introduce a `TestSuite` enum to stop using stringly-typed test suite names where test mode names can be the same as test suite names, and we also have a bunch of other "modes" in compiletest. Make this as unambiguous as possible. A corollary is that now it's more natural to reference via intra-doc links as ``[`TestMode`]``.
- Commit 5: Ditto on `TestSuite`, stop glob-reexporting `TestMode::*` variants, and always use `EnumName::VariantName` form.
- Commit 6: Apparently, `src/tools/rustdoc-gui-test/` depends on `compiletest` for `//@ {compile,run}-paths` directive parsing and extraction, which involves creating a dummy `compiletest` config (hence the existence of the default impls removed in Commit 3). Make this a specific associated function with a FIXME pointing to rust-lang/rust#143827 as I think this setup is quite questionable.
Commits {4, 5} are also intended to help improve the self-consistency in nomenclature used within compiletest.
Best reviewed commit-by-commit.
Disambiguate between rustc vs std having debug assertions in `run-make-support` and `run-make` tests
`NO_DEBUG_ASSERTIONS` is set by CI that threads through to the `./configure.py` script, which is somewhat fragile and "spooky action at a distance". For `fmt-write-bloat`, this is actually wrong because the test wants to gate on *std* being built with debug assertions or not, whereas `NO_DEBUG_ASSERTIONS` determines *rustc* being built with debug assertions or not. Instead, use env vars controlled by compiletest, whose debug assertion info comes from bootstrap.
855e0fe46e/src/ci/run.sh (L137-L146)
`NO_DEBUG_ASSERTIONS` controls `--enable-debug-assertions`
855e0fe46e/src/bootstrap/configure.py (L124)
which sets `--rust.debug-assertions`, which controls *rustc* debug assertions.
855e0fe46e/src/bootstrap/configure.py (L125-L129)
`--rust.debug-assertions-std` controls *std* debug assertions.
Noticed while investigating `fmt-write-bloat` in https://github.com/rust-lang/rust/pull/143669#discussion_r2200522215.
Best reviewed commit-by-commit.
r? ``@ChrisDenton`` (or compiler/bootstrap)
de-duplicate condition scoping logic between AST→HIR lowering and `ScopeTree` construction
There was some overlap between `rustc_ast_lowering::LoweringContext::lower_cond` and `rustc_hir_analysis::check::region::resolve_expr`, so I've removed the former and migrated its logic to the latter, with some simplifications.
Consequences:
- For `while` and `if` expressions' `let`-chains, this changes the `HirId`s for the `&&`s to properly correspond to their AST nodes. This is how guards were handled already.
- This makes match guards share previously-duplicated logic with `if`/`while` expressions. This will also be used by guard pattern[^1] guards.
- Aside from legacy syntax extensions (e.g. some builtin macros) that directly feed AST to the compiler, it's currently impossible to put attributes directly on `&&` operators in `let` chains[^2]. Nonetheless, attributes on `&&` operators in `let` chains in `if`/`while` expression conditions are no longer silently ignored and will be lowered.
- This no longer wraps conditions in `DropTemps`, so the HIR and THIR will be slightly smaller.
- `DesugaringKind::CondTemporary` is now gone. It's no longer applied to any spans, and all uses of it were dead since they were made to account for `if` and `while` being desugared to `match` on a boolean scrutinee.
- Should be a marginal perf improvement beyond that due to leveraging [`ScopeTree` construction](5e749eb66f/compiler/rustc_hir_analysis/src/check/region.rs (L312-L355))'s clever handling of `&&` and `||`:
- This removes some unnecessary terminating scopes that were placed around top-level `&&` and `||` operators in conditions. When lowered to MIR, logical operator chains don't create intermediate boolean temporaries, so there's no temporary to drop. The linked snippet handles wrapping the operands in terminating scopes as necessary, in case they create temporaries.
- The linked snippet takes care of letting `let` temporaries live and terminating other operands, so we don't need separate traversals of `&&` chains for that.
[^1]: rust-lang/rust#129967
[^2]: Case-by-case, here's my justification: `#[attr] e1 && e2` applies the attribute to `e1`. In `#[attr] (e1 && e2)` , the attribute is on the parentheses in the AST, plus it'd fail to parse if `e1` or `e2` contains a `let`. In `#[attr] expands_to_let_chain!()`, the attribute would already be ignored (rust-lang/rust#63221) and it'd fail to parse anyway; even if the expansion site is a condition, the expansion wouldn't be parsed with `Restrictions::ALLOW_LET`. If it *was* allowed, the notion of a "reparse context" from https://github.com/rust-lang/rust/issues/61733#issuecomment-509626449 would be necessary in order to make `let`-chains left-associative; multiple places in the compiler assume they are.
Split up the `unknown_or_malformed_diagnostic_attributes` lint
This splits up the lint into the following lint group:
- `unknown_diagnostic_attributes` - triggers if the attribute is unknown to the current compiler
- `misplaced_diagnostic_attributes` - triggers if the attribute exists but it is not placed on the item kind it's meant for
- `malformed_diagnostic_attributes` - triggers if the attribute's syntax or options are invalid
- `malformed_diagnostic_format_literals` - triggers if the format string literal is invalid, for example if it has unpaired curly braces or invalid parameters
- this pr doesn't create it, but future lints for things like deprecations can also go here.
This PR does not start emitting lints in places that previously did not.
## Motivation
I want to have finer control over what `unknown_or_malformed_diagnostic_attributes` does
I have a project with fairly low msrv that is/will have a lower msrv than future diagnostic attributes. So lints will be emitted when I or others compile it on a lower msrv.
At this time, there are two options to silence these lints:
- `#[allow(unknown_or_malformed_diagnostic_attributes)]` - this risks diagnostic regressions if I (or others) mess up using the attribute, or if the attribute's syntax ever changes.
- write a build script to detect the compiler version and emit cfgs, and then conditionally enable the attribute:
```rust
#[cfg_attr(rust_version_99, diagnostic::new_attr_in_rust_99(thing = ..))]`
struct Foo;
```
or conditionally `allow` the lint:
```rust
// lib.rs
#![cfg_attr(not(current_rust), allow(unknown_or_malformed_diagnostic_attributes))]
```
I like to avoid using build scripts if I can, so the following works much better for me. That is what this PR will let me do in the future:
```rust
#[allow(unknown_diagnostic_attribute, reason = "attribute came out in rust 1.99 but msrv is 1.70")]
#[diagnostic::new_attr_in_rust_99(thing = ..)]`
struct Foo;
Rollup of 9 pull requests
Successful merges:
- rust-lang/rust#143403 (Port several trait/coherence-related attributes the new attribute system)
- rust-lang/rust#143633 (fix: correct assertion to check for 'noinline' attribute presence before removal)
- rust-lang/rust#143647 (Clarify and expand documentation for std::sys_common dependency structure)
- rust-lang/rust#143716 (compiler: doc/comment some codegen-for-functions interfaces)
- rust-lang/rust#143747 (Add target maintainer information for aarch64-unknown-linux-musl)
- rust-lang/rust#143759 (Fix typos in function names in the `target_feature` test)
- rust-lang/rust#143767 (Bump `src/tools/x` to Edition 2024 and some cleanups)
- rust-lang/rust#143769 (Remove support for SwitchInt edge effects in backward dataflow)
- rust-lang/rust#143770 (build-helper: clippy fixes)
r? `@ghost`
`@rustbot` modify labels: rollup
I would like to introduce `TestSuite` over stringly-typed test suite
names, and some test suite names are the same as test modes, which can
make this very confusing.
It is *critical* that we maintain clear nomenclature in `compiletest`.
We have many types of "modes" in `compiletest` -- pass modes, coverage
modes, compare modes, you name it. `Mode` is also a *super* general
term. Rename it to `TestMode` to leave no room for such ambiguity.
As a follow-up, I also intend to introduce an enum for `TestSuite`, then
rid of all usage of glob re-exported `TestMode::*` enum variants -- many
test suites share the same name as the test mode.
Additionally, `NO_DEBUG_ASSERTIONS` is set by CI that threads through to
the `./configure` script, which is somewhat fragile and "spooky action
at a distance". Instead, use env vars controlled by compiletest, whose
debug assertion info comes from bootstrap.
fix: Include frontmatter in -Zunpretty output
In the implementation (rust-lang/rust#140035), this was left as an open question for
the tracking issue (rust-lang/rust#136889). My assumption is that this should be
carried over.
The test was carried over from rust-lang/rust#137193 which was superseded by rust-lang/rust#140035.
Thankfully, either way, `-Zunpretty` is unstable and we can always
change it even if we stabilize frontmatter.
Assorted `run-make-support` maintenance
This PR should contain no functional changes.
- Commit 1: Removes the support library's CHANGELOG. In the very beginning, I thought maybe we would try to version this library. But this is a purely internal test support library, and it's just extra busywork trying to maintain changelog/versions. It's also hopelessly outdated.
- Commit 2: Resets version number to `0.0.0`. Ditto on busywork.
- Commit 3: Bump `run-make-support` to Edition 2024. The support library was already "compliant" with Edition 2024.
- Commit 4: Slightly organizes the support library dependencies.
- Commit 5: Previously, I tried hopelessly to maintain some manual formatting, but that was annoying because it required skipping rustfmt (so export ordering etc. could not be extra formatted). Give up, and do some rearrangements / module prefix tricks to get the `lib.rs` looking at least *reasonable*. IMO this is not a strict improvement, but I rather regain the ability to auto-format it with rustfmt.
- Commit {6,7}: Noticed in rust-lang/rust#143669 that we apparently had *both* {`is_msvc`, `is_windows_msvc`}. This PR removes `is_msvc` in favor of `is_windows_msvc` to make it unambiguous (and only retain one way of gating) as there are some UEFI targets which are MSVC but not Windows.
Best reviewed commit-by-commit.
r? `@Kobzol`
tidy: add support for `--extra-checks=auto:` feature
in preparation for rust-lang/rust#142924
also heavily refactored the parsing of the `--extra-checks` argument to warn about improper usage.
cc ```@GuillaumeGomez```
r? ```@Kobzol```
