Split coroutine desugaring kind from source
What a coroutine is desugared from (gen/async gen/async) should be separate from where it comes (fn/block/closure).
Separate MIR lints from validation
Add a MIR lint pass, enabled with -Zlint-mir, which identifies undefined or
likely erroneous behaviour.
The initial implementation mostly migrates existing checks of this nature from
MIR validator, where they did not belong (those checks have false positives and
there is nothing inherently invalid about MIR with undefined behaviour).
Fixes#104736Fixes#104843Fixes#116079Fixes#116736Fixes#118990
Extract `layout_of_{struct,enum}` fn
While writing #118974 I noticed it was annoying to navigate a huge, several hundred line function, which handles many subcases, and make confident declarations about what part of the flow of execution the compiler would be in. To help with that, this breaks out `layout_of_struct_or_enum`'s fundamental logic into a pair of functions, one for each case. It changes essentially none of that logic, merely moves it around.
Because "the layout of an ADT" feels like a somewhat nebulous subject, I chose to deliberately avoid any expansions to LayoutCalculator's public API, though such does feel like a possible logical next step. There are, indeed, many logical next steps. I'm not taking any of them here, yet, because this comparatively tiny refactor is a prerequisite for all of them.
There are only three. It's simpler to make the type
`DiagnosticBuilder<'_, ()>` from the start, no matter the level, than to
change the guarantee later.
Lots of vectors of messages called `message` or `msg`. This commit
pluralizes them.
Note that `emit_message_default` and `emit_messages_default` both
already existed, and both process a vector, so I renamed the former
`emit_messages_default_inner` because it's called by the latter.
`DiagCtxt::span_bug` is different to the other `DiagCtxt::span_*`
methods. This commit makes it the same, which requires changing
`DiagCtxt::span_delayed_bug` to not do everything within the
`inner.borrow_mut()`.
- Take a `Vec` instead of an iterator, because that's all that is
needed.
- Do an early return for the "no bugs" case.
- Use `enumerate` and an `i == 0` test to identify the first bug.
Those changes mean the `no_bug` variable can be removed, which I found
hard to read.
`IntoDiagnostic` defaults to `ErrorGuaranteed`, because errors are the
most common diagnostic level. It makes sense to do likewise for the
closely-related (and much more widely used) `DiagnosticBuilder` type,
letting us write `DiagnosticBuilder<'a, ErrorGuaranteed>` as just
`DiagnosticBuilder<'a>`. This cuts over 200 lines of code due to many
multi-line things becoming single line things.
We can just get the error level in the `match` and then use
`DiagnosticBuilder::new`. This then means a number of `DiagCtxt`
functions are no longer needed, because this was the one place that used
them.
Note: the commit changes the treatment of spans for `Expect`, which was
different to all the other cases, but this has no apparent effect.
Rollup of 5 pull requests
Successful merges:
- #117601 (Add support for hexagon-unknown-none-elf as target)
- #119169 (Rid the AST & HIR pretty printer of cruft)
- #119194 (Run fuchsia tests only on nightly)
- #119201 (tests: fix overaligned-constant to not over-specify getelementptr instr)
- #119215 (Emits error if has bound regions)
r? `@ghost`
`@rustbot` modify labels: rollup
tests: fix overaligned-constant to not over-specify getelementptr instr
On LLVM 18 we get slightly different arguments here, so it's easier to just regex those away. The important details are all still asserted as I understand things.
Fixes#119193.
`@rustbot` label: +llvm-main
Run fuchsia tests only on nightly
We discovered in https://github.com/rust-lang/rust/pull/119187 that the Fuchsia tests only work on nightly, and so we cannot have the `x86_64-gnu-integration` job run on beta and stable. This PR gates the job to only run in the nightly channel.
r? `@tmandry`
Rid the AST & HIR pretty printer of cruft
Found while working on #119163.
For `trait Trait: ?Sized {}` (semantically malformed), we currently output `trait Trait for ? Sized {}` (sic!) / `trait Trait for ? Sized { }` (sic!) if `-Zunpretty=expanded` / `-Zunpretty=hir` is passed.
`trait Tr for Sized? {}` (#15521) and later also `trait Tr for ?Sized {}` (I guess, #20194) is former Rust syntax. Hence I'm removing these outdated branches.
~~This will conflict with #119163, therefore marking this PR as blocked.~~ Rebased
Add support for `for await` loops
This adds support for `for await` loops. This includes parsing, desugaring in AST->HIR lowering, and adding some support functions to the library.
Given a loop like:
```rust
for await i in iter {
...
}
```
this is desugared to something like:
```rust
let mut iter = iter.into_async_iter();
while let Some(i) = loop {
match core::pin::Pin::new(&mut iter).poll_next(cx) {
Poll::Ready(i) => break i,
Poll::Pending => yield,
}
} {
...
}
```
This PR also adds a basic `IntoAsyncIterator` trait. This is partly for symmetry with the way `Iterator` and `IntoIterator` work. The other reason is that for async iterators it's helpful to have a place apart from the data structure being iterated over to store state. `IntoAsyncIterator` gives us a good place to do this.
I've gated this feature behind `async_for_loop` and opened #118898 as the feature tracking issue.
r? `@compiler-errors`
Exhaustiveness: reveal opaque types properly
Previously, exhaustiveness had no clear policy around opaque types. In this PR I propose the following policy: within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
I'm not sure how consistent this is with other operations allowed on opaque types; I believe this will require FCP.
From what I can tell, this doesn't change anything for non-empty types.
The observable changes are:
- when the real type is uninhabited, matches within the defining scopes can now rely on that for exhaustiveness, e.g.:
```rust
#[derive(Copy, Clone)]
enum Void {}
fn return_never_rpit(x: Void) -> impl Copy {
if false {
match return_never_rpit(x) {}
}
x
}
```
- this properly fixes ICEs like https://github.com/rust-lang/rust/issues/117100 that occurred because a same match could have some patterns where the type is revealed and some where it is not.
Bonus subtle point: if `x` is opaque, a match like `match x { ("", "") => {} ... }` will constrain its type ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=901d715330eac40339b4016ac566d6c3)). This is not the case for `match x {}`: this will not constain the type, and will only compile if something else constrains the type to be empty.
Fixes https://github.com/rust-lang/rust/issues/117100
r? `@oli-obk`
Edited for precision of the wording
[Included](https://github.com/rust-lang/rust/pull/116821#issuecomment-1813171764) in the FCP on this PR is this rule:
> Within the body of an item that defines the hidden type of some opaque type, exhaustiveness checking on a value of that opaque type is performed using the concrete hidden type inferred in this body.
Refactor AST trait bound modifiers
Instead of having two types to represent trait bound modifiers in the parser / the AST (`parser::ty::BoundModifiers` & `ast::TraitBoundModifier`), only to map one to the other later, just use `parser::ty::BoundModifiers` (moved & renamed to `ast::TraitBoundModifiers`).
The struct type is more extensible and easier to deal with (see [here](https://github.com/rust-lang/rust/pull/119099/files#r1430749981) and [here](https://github.com/rust-lang/rust/pull/119099/files#r1430752116) for context) since it more closely models what it represents: A compound of two kinds of modifiers, constness and polarity. Modeling this as an enum (the now removed `ast::TraitBoundModifier`) meant one had to add a new variant per *combination* of modifier kind, which simply isn't scalable and which lead to a lot of explicit non-DRY matches.
NB: `hir::TraitBoundModifier` being an enum is fine since HIR doesn't need to worry representing invalid modifier kind combinations as those get rejected during AST validation thereby immensely cutting down the number of possibilities.
On LLVM 18 we get slightly different arguments here, so it's easier to
just regex those away. The important details are all still asserted as I
understand things.
Fixes#119193.
@rustbot label: +llvm-main
