Run `eval_config_entry` on all branches so we always emit lints
Fixes https://github.com/rust-lang/rust/issues/149090
Ideally I'd have liked to fix this issue using https://github.com/rust-lang/rust/pull/149215, and this is still the long term plan, but this is slightly more annoying to implement than I'd have liked to, and this is also a nice and easy solution to the problem.
r? `@tgross35`
rustc_borrowck: Don't suggest changing closure param type not under user control
This changes output of a handful of tests more than the one added in the first commit, but as far as I can tell, all removed suggestions were invalid.
Closesrust-lang/rust#128381 which is **D-invalid-suggestion** with two 👍-votes.
Gate tests with the right edition
This PR guarantees that `./x test --test-args="--edition XXXX" ui` runs correctly with the 2015, 2018 and 2021 editions.
I don't expect this PR to hold up over time but it helps to submit further updates to the `//@ edition` directives of tests where we can use the new range syntax to have a more robust testing across different editions
r? `@fmease`
---
try-job: aarch64-gnu
try-job: aarch64-apple
try-job: x86_64-msvc-1
try-job: i686-msvc-1
try-job: x86_64-mingw-1
try-job: test-various
try-job: armhf-gnu
remove session+blob decoder construction
turns out, we only did that in one place and we didn't need it.... Working on ways to make this statically known in the future. For now just a smol deletion :3
Port the `#![windows_subsystem]` attribute to the new attribute system
Part of rust-lang/rust#131229.
I think it's worth running the Windows test suite before merging that (I don't have the rights for this).
Rollup of 6 pull requests
Successful merges:
- rust-lang/rust#148256 (remove support for `typeof`)
- rust-lang/rust#148589 (Rename `DropGuard::into_inner` to `DropGuard::dismiss`)
- rust-lang/rust#149001 (Fix false positive of "multiple different versions of crate X in the dependency graph")
- rust-lang/rust#149334 (fix ICE: rustdoc: const parameter types cannot be generic rust-lang/rust#149288)
- rust-lang/rust#149345 (Deeply normalize param env in `compare_impl_item` if using the next solver)
- rust-lang/rust#149367 (Tidying up UI tests [4/N])
r? `@ghost`
`@rustbot` modify labels: rollup
Tidying up UI tests [4/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed prior to merge.
part of rust-lang/rust#133895
Relocate 4 tests in fn-main and issues and remove fn-main directory
r? Kivooeo
Rename `DropGuard::into_inner` to `DropGuard::dismiss`
Tracking issue: https://github.com/rust-lang/rust/issues/144426
One of the open questions blocking the stabilization of `DropGuard` is what to name the associated method that prevents the destructor from running, and returns the captured value. This method is currently called `into_inner`, but most people (including myself) feel like this would benefit from a method that calls more attention to itself.
This PR proposes naming this method `dismiss`, after the Linux kernel's [`ScopeGuard::dismiss`](https://rust.docs.kernel.org/kernel/types/struct.ScopeGuard.html#method.dismiss). Which crucially does not evoke images of violence or weaponry the way alternatives such as "disarm" or "defuse" do. And personally I enjoy the visual metaphor of "dismissing a guard" (e.g. a person keeping watch over something) - a job well done, they're free to go.
This PR also changes the signature from an static method to an instance method. This also matches the Linux kernel's API, and seems alright since `dismiss` is not nearly as ubiquitous as `into_inner`. This makes it more convenient to use, with a much lower risk of conflicting. Though in the rare case there might be ambiguity, the explicit notation is available as a fallback.
```rust
let x = DropGuard::into_inner(guard); // ← current
let x = guard.dismiss(); // ← proposed
Relocate issues/issue-51022.rs to
entry-point/main-with-lifetime-param.rs
Relocate issue-50714.rs to entry-point/main-where-fn-bound.rs
Rename issue-118772.rs to main-with-invalid-signature.rs and delete
duplicate test
remove ui/entry-point/issue-118772.rs in issues.txt
Relocate fn-main/wrong-location.rs to entry-point/main-in-submodule.rs
Remove fn-main directory
Relocate issue-50688.rs to mismatched_types/array-len-is-closure.rs
bootstrap: Replace `Step::DEFAULT` and `default_condition` with `is_default_step`
- Revised and expanded version of https://github.com/rust-lang/rust/pull/148965
---
One of the confusing things about bootstrap's `Step::should_run` is that it combines two loosely-related but non-overlapping responsibilities:
- Registering paths/aliases to decide whether a step should be run in response to paths/aliases passed as explicit command-line arguments
- When the user invokes `./x test compiler`, this allows bootstrap to know what steps “compiler” should translate into
- Deciding whether a step marked `DEFAULT = true` should actually run or not, when no paths/aliases are explicitly specified
- When the user invokes `./x test`, this allows bootstrap to know which steps to run by default
This PR therefore splits out the latter of those responsibilities into a dedicated `is_default_step` associated function, which also replaces the existing `DEFAULT` associated constant.
A small number of steps were using `ShouldRun::lazy_default_condition` to specify a condition that should not be run repeatedly if possible, e.g. because it queries external tools. Those steps now perform memoization via fields in `Builder` instead.
r? jieyouxu
Stuart Cook