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`
Re-expose nested bodies in rustc_borrowck::consumers
After https://github.com/rust-lang/rust/pull/138499, it's not possible anymore to get borrowck information for nested bodies via `get_body_with_borrowck_facts`. This PR re-exposes nested bodies by returning a map containing the typeck root and all its nested bodies. To collect the bodies, a map is added to `BorrowCheckRootCtxt`, and a body is inserted every time `do_mir_borrowck` is called.
r? ``@lcnr``
`tests/ui`: A New Order [23/N]
> [!NOTE]
>
> Intermediate commits are intended to help review, but will be squashed prior to merge.
Some `tests/ui/` housekeeping, to trim down number of tests directly under `tests/ui/`. Part of rust-lang/rust#133895.
r? ``@tgross35``
Make lint `ambiguous_glob_imports` deny-by-default and report-in-deps
This pr aims to finish the second part of rust-lang/rust#114095. It converts the `ambiguous_glob_imports` lint from a warning to an error.
Currently, only the lint definition and the related tests are changed, a crater run should provide us with information on whether we should go for this.
mbe: Rework diagnostics for metavariable expressions
Make the diagnostics for metavariable expressions more user-friendly. This mostly addresses syntactic errors; I will be following up with improvements to `concat(..)`.
Fix `proc_macro::Ident`'s handling of `$crate`
This PR is addresses a few minor bugs, all relating to `proc_macro::Ident`'s support for `$crate`. `Ident` currently supports `$crate` (as can be seen in the `mixed-site-span` test), but:
* `proc_macro::Symbol::can_be_raw` is out of sync with `rustc_span::Symbol::can_be_raw`
* former doesn't cover `$crate` while the latter does cover `kw::DollarCrate`
* `Ident::new` rejects `$crate`
* This conflicts with the [reference definition](https://doc.rust-lang.org/nightly/reference/macros-by-example.html#r-macro.decl.meta.specifier) of `ident` which includes `$crate`.
* This also conflicts with the documentation on [`Display for Ident`](https://doc.rust-lang.org/proc_macro/struct.Ident.html#impl-Display-for-Ident) which says the output "should be losslessly convertible back into the same identifier".
This PR fixes the above issues and extends the `mixed-site-span` test to exercise these fixed code paths, as well as validating the different possible spans resolve `$crate` as expected (for both the new and old `$crate` construction code paths).
Give a more user-friendly diagnostic about the following:
* Trailing tokens within braces, e.g. `${foo() extra}`
* Missing parentheses, e.g. `${foo}`
* Incorrect number of arguments, with a hint about correct usage.
Let `rvalue_creates_operand` return true for *all* `Rvalue::Aggregate`s
~~Draft for now because it's built on Ralf's rust-lang/rust#143291~~
Inspired by https://github.com/rust-lang/rust/pull/138759#discussion_r2156375342 where I noticed that we were nearly at this point, plus the comments I was writing in rust-lang/rust#143410 that reminded me a type-dependent `true` is fine.
This PR splits the `OperandRef::builder` logic out to a separate type, with the updates needed to handle SIMD as well. In doing so, that makes the existing `Aggregate` path in `codegen_rvalue_operand` capable of handing SIMD values just fine.
As a result, we no longer need to do layout calculations for aggregate result types when running the analysis to determine which things can be SSA in codegen.
`rustc_pattern_analysis`: always check that deref patterns don't match on the same place as normal constructors
In rust-lang/rust#140106, deref pattern validation was tied to the `deref_patterns` feature to temporarily avoid affecting perf. However:
- As of rust-lang/rust#143414, box patterns are represented as deref patterns in `rustc_pattern_analysis`. Since they can be used by enabling `box_patterns` instead of `deref_patterns`, it was possible for them to skip validation, resulting in an ICE. This fixes that and adds a regression test.
- External tooling (e.g. rust-analyzer) will also need to validate matches containing deref patterns, which was not possible. This fixes that by making `compute_match_usefulness` validate deref patterns by default.
In order to avoid doing an extra pass for anything with patterns, the second commit makes `RustcPatCtxt` keep track of whether it encounters a deref pattern, so that it only does the check if so. This is purely for performance. If the perf impact of the first commit is negligible and the complexity cost introduced by the second commit is significant, it may be worth dropping the latter.
r? `@Nadrieril`
More carefully consider span context when suggesting remove `&mut`
Use `find_ancestor_inside` to compute a relative span that is macro-aware, rather than falling back to using BytePos arithmetic which is wrong for `&mut`.
Fixes https://github.com/rust-lang/rust/issues/143523
tests: Use `cfg_target_has_reliable_f16_f128` in `conv-bits-runtime-const`
`conv-bits-runtime-const` gates `f16` and `f128` tests behind `x86_64`, but this isn't always accurate. In particular, x86 `MinGW` has an ABI bug [1] which means things work when linked to our Rust math libraries but don't work with host libraries. RUST-143405 slightly adjusts which targets we provide `f16` and `f128` symbols for and effectively removes MinGW from that list, meaning host libraries start getting linked, meaning `f16` and `f128` tests start to fail.
Account for this by changing the gates in one such test to `cfg(target_has_reliable_{f16,f128})` which is the way we should be gating all behavior related to the types going forward.
`rustfmt` also seems to have formatted the macros which is fine.
[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
Respect endianness correctly in CheckEnums test suite
The endianness can change the test expectation for the enum check. This change is fixing the failing tests on big endian by changing the tests so that they behave the same as on little endian.
Fixesrust-lang/rust#143332.
Remove false label when `self` resolve failure does not relate to macro
Fixesrust-lang/rust#143134
In the first commit, I did some code-clean, moving `suggest*` to `suggestions/` dir.
In the second, commit, I added ui test.
In the third, I change the code, and present the test result.
r? compiler
Apply effects to `otherwise` edge in dataflow analysis
This allows `ElaborateDrops` to remove drops when a `match` wildcard arm covers multiple no-Drop enum variants. It modifies dataflow analysis to update the `MaybeUninitializedPlaces` and `MaybeInitializedPlaces` data for a block reached through an `otherwise` edge.
Fixesrust-lang/rust#142705.
Don't mark `#[target_feature]` safe fns as unsafe in rustdoc JSON.
Fixes https://github.com/rust-lang/rust/issues/142655 by explicitly checking whether functions are safe but using `#[target_feature]`, instead of relying on the `FnHeader::is_unsafe()` method which considers such functions unsafe.
I don't believe this merits a bump of the rustdoc JSON `FORMAT_VERSION` constant, since the format is unchanged and this is just a small bugfix.
r? aDotInTheVoid
Port several linking (linkage?) related attributes the new attribute system
This ports:
- `#[export_stable]`
- `#[ffi_const]`
- `#[ffi_pure]`
- `#[rustc_std_internal_symbol]`
Part of rust-lang/rust#131229
r? ``@oli-obk``
- update existing tests for stabilization
- ensure `-Clink-self-contained=-linker` is only stable on x64 linux
- test invalid `-Clink-self-contained` components
This stabilizes a subset of the `-Clink-self-contained` components on x64 linux:
the rust-lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
This stabilizes a subset of the `-Clinker-features` components on x64 linux:
the lld opt-out.
The opt-in is not stabilized, as interactions with other stable flags require
more internal work, but are not needed for stabilizing using rust-lld by default.
Similarly, since we only switch to rust-lld on x64 linux, the opt-out is
only stabilized there. Other targets still require `-Zunstable-options`
to use it.
Inspired by <https://github.com/rust-lang/rust/pull/138759#discussion_r2156375342> where I noticed that we were nearly at this point, plus the comments I was writing in 143410 that reminded me a type-dependent `true` is fine.
This PR splits the `OperandRef::builder` logic out to a separate type, with the updates needed to handle SIMD as well. In doing so, that makes the existing `Aggregate` path in `codegen_rvalue_operand` capable of handing SIMD values just fine.
As a result, we no longer need to do layout calculations for aggregate result types when running the analysis to determine which things can be SSA in codegen.
const-block-as-pattern: do not refer to no-longer-existing nightly feature
Surely everyone who used this nightly feature has fixed their code by now. So let's not confused people on stable that try to use a const block as a pattern by referring to some dead nightly feature.
Point to correct argument in Func Call when Self type fails trait bound
Fixesrust-lang/rust#143336
When a trait bound fails due to the `Self` type parameter, `adjust_fulfillment_errors` now correctly points to the corresponding function argument instead of incorrectly pointing to other arguments. This is because `Call` may also need to handle the `self` parameter, and not just `MethodCall` needs to be handled, as rust-lang/rust#143336.
r? compiler
Do not suggest borrow that is already there in fully-qualified call
When encountering `&str::from("value")` do not suggest `&&str::from("value")`.
Fix#132041.
The endianness can change the test expectation for the enum check.
This change is fixing the failing tests on big endian by changing
the tests so that they behave the same as on little endian.
