Spell out other trait diagnostic
I recently saw somebody confused about the diagnostic thinking it was suggesting to add an `as` cast. This change is longer but I think it's clearer
tests/ui/lint: Move 19 tests to new `non-snake-case` subdir
Mainly so that it is easier to only run all `non_snake_case`-lint-specific tests with:
./x test tests/ui/lint/non-snake-case
But also to reduce the size of the large `tests/ui/lint` directory. And rename some tests to pass tidy, and remove them from `src/tools/tidy/src/issues.txt`.
Check that alias-relate terms are WF if reporting an error in alias-relate
Check that each of the left/right term is WF when deriving a best error obligation for an alias-relate goal. This will make sure that given `<i32 as NotImplemented>::Assoc = ()` will drill down into `i32: NotImplemented` since we currently treat the projection as rigid.
r? lcnr
Mainly so that it is easier to only run all `non-snake-case`-specific
tests but no other tests with:
./x test tests/ui/lint/non-snake-case
But also to reduce the size of the large `tests/ui/lint` directory. And
rename some tests to pass tidy, and remove them from
`src/tools/tidy/src/issues.txt`.
Rollup of 9 pull requests
Successful merges:
- #125829 (rustc_span: Add conveniences for working with span formats)
- #126361 (Unify intrinsics body handling in StableMIR)
- #126417 (Add `f16` and `f128` inline ASM support for `x86` and `x86-64`)
- #126424 ( Also sort `crt-static` in `--print target-features` output)
- #126428 (Polish `std::path::absolute` documentation.)
- #126429 (Add `f16` and `f128` const eval for binary and unary operationations)
- #126448 (End support for Python 3.8 in tidy)
- #126488 (Use `std::path::absolute` in bootstrap)
- #126511 (.mailmap: Associate both my work and my private email with me)
r? `@ghost`
`@rustbot` modify labels: rollup
Add `f16` and `f128` const eval for binary and unary operationations
Add const evaluation and Miri support for f16 and f128, including unary and binary operations. Casts are not yet included.
Fixes https://github.com/rust-lang/rust/issues/124583
r? ``@RalfJung``
Add `f16` and `f128` inline ASM support for `x86` and `x86-64`
This PR adds `f16` and `f128` input and output support to inline ASM on `x86` and `x86-64`. `f16` vector sizes are taken from [here](https://www.intel.com/content/www/us/en/docs/intrinsics-guide/index.html).
Relevant issue: #125398
Tracking issue: #116909
``@rustbot`` label +F-f16_and_f128
Rollup of 9 pull requests
Successful merges:
- #126354 (Use `Variance` glob imported variants everywhere)
- #126367 (Point out failing never obligation for `DEPENDENCY_ON_UNIT_NEVER_TYPE_FALLBACK`)
- #126469 (MIR Shl/Shr: the offset can be computed with rem_euclid)
- #126471 (Use a consistent way to filter out bounds instead of splitting it into three places)
- #126472 (build `libcxx-version` only when it doesn't exist)
- #126497 (delegation: Fix hygiene for `self`)
- #126501 (make bors ignore comments in PR template)
- #126509 (std: suggest OnceLock over Once)
- #126512 (Miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
delegation: Fix hygiene for `self`
And fix diagnostics for `self` from a macro.
The missing rib caused `self` to be treated as a generic parameter and ignore `macro_rules` hygiene.
Addresses this comment https://github.com/rust-lang/rust/pull/124135#discussion_r1637492234.
Point out failing never obligation for `DEPENDENCY_ON_UNIT_NEVER_TYPE_FALLBACK`
Based on top of #125289, so just need to look at the last commit.
r? `@WaffleLapkin`
Don't build a broken/untested profiler runtime on mingw targets
Context: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Why.20build.20a.20broken.2Funtested.20profiler.20runtime.20on.20mingw.3F#75872 added `--enable-profiler` to the `x86_64-mingw` job (to cause some additional tests to run), but had to also add `//@ ignore-windows-gnu` to all of the tests that rely on the profiler runtime actually *working*, because it's broken on that target.
We can achieve a similar outcome by going through all the `//@ needs-profiler-support` tests that don't actually need to produce/run a binary, and making them use `-Zno-profiler-runtime` instead, so that they can run even in configurations that don't have the profiler runtime available. Then we can remove `--enable-profiler` from `x86_64-mingw`, and still get the same amount of testing.
This PR also removes `--enable-profiler` from the mingw dist builds, since it is broken/untested on that target. Those builds have had that flag for a very long time.
Add a new concat metavar expr
Revival of #111930
Giving it another try now that #117050 was merged.
With the new rules, meta-variable expressions must be referenced with a dollar sign (`$`) and this can cause misunderstands with `$concat`.
```rust
macro_rules! foo {
( $bar:ident ) => {
const ${concat(VAR, bar)}: i32 = 1;
};
}
// Will produce `VARbar` instead of `VAR_123`
foo!(_123);
```
In other words, forgetting the dollar symbol can produce undesired outputs.
cc #29599
cc https://github.com/rust-lang/rust/issues/124225
Rollup of 7 pull requests
Successful merges:
- #123769 (Improve escaping of byte, byte str, and c str proc-macro literals)
- #126054 (`E0229`: Suggest Moving Type Constraints to Type Parameter Declaration)
- #126135 (add HermitOS support for vectored read/write operations)
- #126266 (Unify guarantees about the default allocator)
- #126285 (`UniqueRc`: support allocators and `T: ?Sized`.)
- #126399 (extend the check for LLVM build)
- #126426 (const validation: fix ICE on dangling ZST reference)
r? `@ghost`
`@rustbot` modify labels: rollup
const validation: fix ICE on dangling ZST reference
Fixes https://github.com/rust-lang/rust/issues/126393
I'm not super happy with this fix but I can't think of a better one.
r? `@oli-obk`
`E0229`: Suggest Moving Type Constraints to Type Parameter Declaration
Fixes#113073
This PR suggests `impl<T: Bound> Trait<T> for Foo` when finding `impl Trait<T: Bound> for Foo`. Tangentially, it also improves a handful of other error messages.
It accomplishes this in two steps:
1. Check if constrained arguments and parameter names appear in the same order and delay emitting "incorrect number of generic arguments" error because it can be confusing for the programmer to see `0 generic arguments provided` when there are `n` constrained generic arguments.
2. Inside `E0229`, suggest declaring the type parameter right after the `impl` keyword by finding the relevant impl block's span for type parameter declaration. This also handles lifetime declarations correctly.
Also, the multi part suggestion doesn't use the fluent error mechanism because translating all the errors to fluent style feels outside the scope of this PR. I will handle it in a separate PR if this gets approved.
Improve escaping of byte, byte str, and c str proc-macro literals
This PR changes the behavior of `proc_macro::Literal::byte_character` (https://github.com/rust-lang/rust/issues/115268), `byte_string`, and `c_string` (https://github.com/rust-lang/rust/issues/119750) to improve their choice of escape sequences. 3 categories of changes are made:
1. Never use `\x00`. Always prefer `\0`, which is supported in all the same places.
2. Never escape `\'` inside double quotes and `\"` inside single quotes.
3. Never use `\x` for valid UTF-8 in literals that permit `\u`.
The second commit adds tests covering these cases, asserting the **old** behavior.
The third commit implements the behavior change and simultaneously updates the tests to assert the **new** behavior.
change method resolution to constrain hidden types instead of rejecting method candidates
Some of these are in probes and may affect inference. This is therefore a breaking change.
This allows new code to compile on stable:
```rust
trait Trait {}
impl Trait for u32 {}
struct Bar<T>(T);
impl Bar<u32> {
fn foo(self) {}
}
fn foo(x: bool) -> Bar<impl Sized> {
if x {
let x = foo(false);
x.foo();
//^ this used to not find the `foo` method, because while we did equate `x`'s type with possible candidates, we didn't allow opaque type inference while doing so
}
todo!()
}
```
r? ```````@compiler-errors```````
fixes #121404
cc https://github.com/rust-lang/rust/issues/116652
For PGO/coverage tests that don't need to build or run an actual artifact, we
can use `-Zno-profiler-runtime` to run the test even when the profiler runtime
is not available.
Tweak output of import suggestions
When both `std::` and `core::` items are available, only suggest the `std::` ones. We ensure that in `no_std` crates we suggest `core::` items.
Ensure that the list of items suggested to be imported are always in the order of local crate items, `std`/`core` items and finally foreign crate items.
Tweak wording of import suggestion: if there are multiple items but they are all of the same kind, we use the kind name and not the generic "items".
Fix#83564.
Add pub struct with allow(dead_code) into worklist
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
Fixes#126289
When both `std::` and `core::` items are available, only suggest the
`std::` ones. We ensure that in `no_std` crates we suggest `core::`
items.
Ensure that the list of items suggested to be imported are always in the
order of local crate items, `std`/`core` items and finally foreign crate
items.
Tweak wording of import suggestion: if there are multiple items but they
are all of the same kind, we use the kind name and not the generic "items".
Fix#83564.
safe transmute: support `Single` enums
Previously, the implementation of `Tree::from_enum` incorrectly treated enums with `Variants::Single` and `Variants::Multiple` identically. This is incorrect for `Variants::Single` enums, which delegate their layout to that of a variant with a particular index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted to compute the tag of variants other than the one at `Variants::Single`'s `index`, and fell afoul of a sanity-checking assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`. This assertion is non-load-bearing, and can be removed; the routine its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent: calling `Tree::from_variant` on a variant that does not exist is ill-defined. A sanity check the given variant has `FieldShapes::Arbitrary` fails, and the analysis is (correctly) aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that `Tree::from_variant` is not called on variants that are, as far as layout is concerned, nonexistent. Specifically, the implementation of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the first case, `Tree::uninhabited()` is produced. In the second case, the layout is delegated to `Variants::Single`'s index.
Fixes#125811
Harmonize using root or leaf obligation in trait error reporting
When #121826 changed the error reporting to use root obligation and not the leafmost obligation, it didn't actually make sure that all the other diagnostics helper functions used the right obligation.
Specifically, when reporting similar impl candidates we are looking for impls of the root obligation, but trying to match them against the trait ref of the leaf obligation.
This does a few other miscellaneous changes. There's a lot more clean-up that could be done here, but working with this code is really grief-inducing due to how messy it has become over the years. Someone really needs to show it love. 😓
r? ``@estebank``
Fixes#126129
Previously, the implementation of `Tree::from_enum` incorrectly
treated enums with `Variants::Single` and `Variants::Multiple`
identically. This is incorrect for `Variants::Single` enums,
which delegate their layout to that of a variant with a particular
index (or no variant at all if the enum is empty).
This flaw manifested first as an ICE. `Tree::from_enum` attempted
to compute the tag of variants other than the one at
`Variants::Single`'s `index`, and fell afoul of a sanity-checking
assertion in `compiler/rustc_const_eval/src/interpret/discriminant.rs`.
This assertion is non-load-bearing, and can be removed; the routine
its in is well-behaved even without it.
With the assertion removed, the proximate issue becomes apparent:
calling `Tree::from_variant` on a variant that does not exist is
ill-defined. A sanity check the given variant has
`FieldShapes::Arbitrary` fails, and the analysis is (correctly)
aborted with `Err::NotYetSupported`.
This commit corrects this chain of failures by ensuring that
`Tree::from_variant` is not called on variants that are, as far as
layout is concerned, nonexistent. Specifically, the implementation
of `Tree::from_enum` is now partitioned into three cases:
1. enums that are uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
`Tree::from_variant` is now only invoked in the third case. In the
first case, `Tree::uninhabited()` is produced. In the second case,
the layout is delegated to `Variants::Single`'s index.
Fixes#125811
