Print `token::Interpolated` with token stream pretty printing.
This is a step towards removing `token::Interpolated` (#124141). It unavoidably changes the output of the `stringify!` macro, generally for the better.
r? `@petrochenkov`
interpret: ensure we check bool/char for validity when they are used in a cast
In general, `Scalar::to_bits` is a bit dangerous as it bypasses all type information. We should usually prefer matching on the type and acting according to that. So I also refactored `unary_op` handling of integers to do that. The remaining `to_bits` uses are operations that just fundamentally don't care about the sign (and only work on integers).
invalid_char_cast.rs is the key new test, the others already passed before this PR.
r? `@oli-obk`
Rollup of 5 pull requests
Successful merges:
- #125913 (Spruce up the diagnostics of some early lints)
- #126234 (Delegation: fix ICE on late diagnostics)
- #126253 (Simplify assert matchers in `run-make-support`)
- #126257 (Rename `needs-matching-clang` to `needs-force-clang-based-tests`)
- #126259 (reachable computation: clarify comments around consts)
r? `@ghost`
`@rustbot` modify labels: rollup
Spruce up the diagnostics of some early lints
Implement the various "*(note to myself) in a follow-up PR we should turn parts of this message into a subdiagnostic (help msg or even struct sugg)*" drive-by comments I left in #124417 during my review.
For context, before #124417, only a few early lints touched/decorated/customized their diagnostic because the former API made it a bit awkward. Likely because of that, things that should've been subdiagnostics were just crammed into the primary message. This PR rectifies this.
Only compute `specializes` query if (min)specialization is enabled in the crate of the specializing impl
Fixes (after backport) https://github.com/rust-lang/rust/issues/125197
### What
https://github.com/rust-lang/rust/pull/122791 makes it so that inductive cycles are no longer hard errors. That means that when we are testing, for example, whether these impls overlap:
```rust
impl PartialEq<Self> for AnyId {
fn eq(&self, _: &Self) -> bool {
todo!()
}
}
impl<T: Identifier> PartialEq<T> for AnyId {
fn eq(&self, _: &T) -> bool {
todo!()
}
}
```
...given...
```rust
pub trait Identifier: Display + 'static {}
impl<T> Identifier for T where T: PartialEq + Display + 'static {}
```
Then we try to see if the second impl holds given `T = AnyId`. That requires `AnyId: Identifier`, which requires that `AnyId: PartialEq`, which is satisfied by these two impl candidates... The `PartialEq<T>` impl is a cycle, and we used to winnow it when we used to treat inductive cycles as errors.
However, now that we don't winnow it, this means that we *now* try calling `candidate_should_be_dropped_in_favor_of`, which tries to check whether one of the impls specializes the other: the `specializes` query. In that query, we currently bail early if the impl is local.
However, in a foreign crate, we try to compute if the two impls specialize each other by doing trait solving. This may itself lead to the same situation where we call `specializes`, which will lead to a query cycle.
### How does this fix the problem
We now record whether specialization is enabled in foreign crates, and extend this early-return behavior to foreign impls too. This means that we can only encounter these cycles if we truly have a specializing impl from a crate with specialization enabled.
-----
r? `@oli-obk` or `@lcnr`
Add `SingleUseConsts` mir-opt pass
The goal here is to make a pass that can be run in debug builds to simplify the common case of constants that are used just once -- that doesn't need SSA handling and avoids any potential downside of multi-use constants. In particular, to simplify the `if T::IS_ZST` pattern that's common in the standard library.
By also handling the case of constants that are *never* actually used this fully replaces the `ConstDebugInfo` pass, since it has all the information needed to do that naturally from the traversal it needs to do anyway.
This is roughly a wash on instructions on its own (a couple regressions, a few improvements https://github.com/rust-lang/rust/pull/125910#issuecomment-2144963361), with a bunch of size improvements. So I'd like to land it as its own PR, then do follow-ups to take more advantage of it (in the inliner, cg_ssa, etc).
r? `@saethlin`
Add explanatory note to async block type mismatch error
The async block type mismatch error might leave the user wondering as to why it occurred. The new note should give them the needed context.
Changes this diagnostic:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
```
to this:
```
error[E0308]: mismatched types
--> src/main.rs:5:23
|
2 | let a = async { 1 };
| ----------- the expected `async` block
3 | let b = async { 2 };
| ----------- the found `async` block
4 |
5 | let bad = vec![a, b];
| ^ expected `async` block, found a different `async` block
|
= note: expected `async` block `{async block@src/main.rs:2:13: 2:24}`
found `async` block `{async block@src/main.rs:3:13: 3:24}`
= note: no two async blocks, even if identical, have the same type
= help: consider pinning your async block and and casting it to a trait object
```
Fixes#125737
Fix ICE due to `unwrap` in `probe_for_name_many`
Fixes#125876
Now `probe_for_name_many` bubbles up the error returned by `probe_op` instead of calling `unwrap` on it.
Enable GVN for `AggregateKind::RawPtr`
Looks like I was worried for nothing; this seems like it's much easier than I was originally thinking it would be.
r? `@cjgillot`
This should be useful for `x[..4]`-like things, should those start inlining enough to expose the lengths.
simd packed types: remove outdated comment, extend codegen test
It seems like https://github.com/rust-lang/rust/pull/125311 made that check in codegen unnecessary?
r? `@workingjubilee` `@calebzulawski`
offset_of: allow (unstably) taking the offset of slice tail fields
Fields of type `[T]` have a statically known offset, so there is no reason to forbid them in `offset_of!`. This PR adds the `offset_of_slice` feature to allow them.
I created a tracking issue: https://github.com/rust-lang/rust/issues/126151.
mark binding undetermined if target name exist and not obtained
- Fixes#124490
- Fixes#125013
Following up on #124840, I think handling only `target_bindings` is sufficient.
r? `@petrochenkov`
Revert "Use the HIR instead of mir_keys for determining whether something will have a MIR body."
This reverts commit e5cba17b84.
turns out SMIR still needs it (https://github.com/model-checking/kani/issues/3218). I'll create a full plan and MCP for what I intended this to be a part of. Maybe my plan is nonsense anyway.
Detect pub structs never constructed and unused associated constants
<!--
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>
-->
Lints never constructed public structs.
If we don't provide public methods to construct public structs with private fields, and don't construct them in the local crate. They would be never constructed. So that we can detect such public structs.
---
Update:
Also lints unused associated constants in traits.
Parse unsafe attributes
Initial parse implementation for #123757
This is the initial work to parse unsafe attributes, which is represented as an extra `unsafety` field in `MetaItem` and `AttrItem`. There's two areas in the code where it appears that parsing is done manually and not using the parser stuff, and I'm not sure how I'm supposed to thread the change there.
Revert: create const block bodies in typeck via query feeding
as per the discussion in https://github.com/rust-lang/rust/pull/125806#discussion_r1622563948
It was a mistake to try to shoehorn const blocks and some specific anon consts into the same box and feed them during typeck. It turned out not simplifying anything (my hope was that we could feed `type_of` to start avoiding the huge HIR matcher, but that didn't work out), but instead making a few things more fragile.
reverts the const-block-specific parts of https://github.com/rust-lang/rust/pull/124650
`@bors` rollup=never had a small perf impact previously
fixes https://github.com/rust-lang/rust/issues/125846
r? `@compiler-errors`
Revert "Disallow ambiguous attributes on expressions" on nightly
As discussed in [today's t-compiler meeting](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202024-06-06/near/443079505), this reverts PR #124099 to fix P-critical beta regressions #125199.
r? ``@wesleywiser``
Opening as draft so that ``@wesleywiser`` and ``@apiraino,`` you can tell me whether you wanted:
1. a `beta-accepted` revert of #124099 on nightly (this PR)? That will need to be backported to beta (even though #126093 may be the last of those)
2. a revert of #124099 on beta?
3. all of the above?
I also opened #126102, another draft PR to revert #124099 on beta, should you choose options 2 or 3.
