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.
Previously, `Tree::from_enum`'s implementation branched into three disjoint
cases:
1. enums that uninhabited
2. enums for which all but one variant is uninhabited
3. enums with multiple inhabited variants
This branching (incorrectly) did not differentiate between variantful and
variantless uninhabited enums. In both cases, we assumed (and asserted) that
uninhabited enums are zero-sized types. This assumption is false for enums like:
enum Uninhabited { A(!, u128) }
...which, currently, has the same size as `u128`. This faulty assumption
manifested as the ICE reported in #126460.
In this PR, we revise the first case of `Tree::from_enum` to consider only the
narrow category of "enums that are uninhabited ZSTs". These enums, whose layouts
are described with `Variants::Single { index }`, are special in their layouts
otherwise resemble the `!` type and cannot be descended into like typical enums.
This first case captures uninhabited enums like:
enum Uninhabited { A(!, !), B(!) }
The second case is revised to consider the broader category of "enums that defer
their layout to one of their variants"; i.e., enums whose layouts are described
with `Variants::Single { index }` and that do have a variant at `index`. This
second case captures uninhabited enums that are not ZSTs, like:
enum Uninhabited { A(!, u128) }
...which represent their variants with `Variants::Single`.
Finally, the third case is revised to cover the broader category of "enums with
multiple variants", which captures uninhabited, non-ZST enums like:
enum Uninhabited { A(u8, !), B(!, u32) }
...which represent their variants with `Variants::Multiple`.
This PR also adds a comment requested by RalfJung in his review of #126358 to
`compiler/rustc_const_eval/src/interpret/discriminant.rs`.
Fixes#126460
This deprecates `-Cinline-threshold` since using it has no effect. This
has been the case since the new LLVM pass manager started being used,
more than 2 years ago.
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.
