`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.
Dont resolve instance of root in `mir_callgraph_cyclic`
`Instance::try_resolve` on a default trait body method will always fail, since it's still possible to further substitute. This leads to a cycle, since in `tests/mir-opt/inline_default_trait_body.rs`, both `Trait::a` and `Trait::b` need to consider the other to be cyclical, but since we couldn't resolve a body, we'd just consider *nothing* to be cyclical.
The root instance we care about when computing `mir_callgraph_cyclic` is trivial to compute (it's just `InstanceKind::Item`), so just replace it with a call to `Instance::new_raw`.
r? `@cjgillot` `@oli-obk`
Fixesrust-lang/rust#143534
Move `stable_mir` back to its own crate
We've finished the refactoring, so it's time to move `stable_mir` back to its own crate.
This PR leaves an empty `rustc_internal` module with a `#[deprecated]` attribute in `rustc_smir` to let users know we just moved it to `stable_mir`.
Fix short linker error output
This PR does 2 things:
- It removes the braces when there's a single element. This is required since brace expansion (at least in bash and zsh) only triggers if there's at least 2 elements.
- It removes the extra `.rlib` suffixes of the elements. See https://github.com/rust-lang/rust/pull/135707#discussion_r2185212393 for context.
Running `cargo +stage1 build` on the following program:
```rust
unsafe extern "C" {
fn foo() -> libc::c_int;
}
fn main() {
let x = unsafe { foo() } as u32;
// println!("{}", data_encoding::BASE64.encode(&x.to_le_bytes()));
}
```
Gives the following diff before and after the PR:
```diff
-/tmp/foo/target/debug/deps/{liblibc-faf416f178830595.rlib}.rlib
+/tmp/foo/target/debug/deps/liblibc-faf416f178830595.rlib
```
Running on the same program with the additional dependency, we get the following diff:
```diff
-/tmp/foo/target/debug/deps/{liblibc-faf416f178830595.rlib,libdata_encoding-84bb5aadfa9e8839.rlib}.rlib
+/tmp/foo/target/debug/deps/{liblibc-faf416f178830595,libdata_encoding-84bb5aadfa9e8839}.rlib
```
