It's a level of indirection that hurts far more than it helps. The code
is simpler without it. (This commit cuts more than 120 lines of code.)
In particular, this commit removes some unnecessary `Span`s within
`DeclKind` that were always identical to those in the enclosing `Stmt`,
and some unnecessary allocations via `P`.
Benefits:
- It lets us move the `NodeId` field out of every `hir::StmtKind`
variant `NodeId` to a more sensible spot.
- It eliminates sadness in `Stmt::fmt`.
- It makes `hir::Stmt` match `ast::Stmt`.
Implement RFC 2338, "Type alias enum variants"
This PR implements [RFC 2338](https://github.com/rust-lang/rfcs/pull/2338), allowing one to write code like the following.
```rust
#![feature(type_alias_enum_variants)]
enum Foo {
Bar(i32),
Baz { i: i32 },
}
type Alias = Foo;
fn main() {
let t = Alias::Bar(0);
let t = Alias::Baz { i: 0 };
match t {
Alias::Bar(_i) => {}
Alias::Baz { i: _i } => {}
}
}
```
Since `Self` can be considered a type alias in this context, it also enables using `Self::Variant` as both a constructor and pattern.
Fixes issues #56199 and #56611.
N.B., after discussing the syntax for type arguments on enum variants with @petrochenkov and @eddyb (there are also a few comments on the [tracking issue](https://github.com/rust-lang/rust/issues/49683)), the consensus seems to be treat the syntax as follows, which ought to be backwards-compatible.
```rust
Option::<u8>::None; // OK
Option::None::<u8>; // OK, but lint in near future (hard error next edition?)
Alias::<u8>::None; // OK
Alias::None::<u8>; // Error
```
I do not know if this will need an FCP, but let's start one if so.
`CrateRoot` -> `PathRoot`, `::` doesn't necessarily mean crate root now
`SelfValue` -> `SelfLower`, `SelfType` -> `SelfUpper`, both `self` and `Self` can be used in type and value namespaces now
`Printer::word` takes a `&str` and converts it into a `String`, which
causes an allocation. But that allocation is rarely necessary, because
`&str` is almost always a `&'static str` or a `String` that won't be
used again.
This commit changes `Token::String` so it holds a `Cow<'static, str>`
instead of a `String`, which avoids a lot of allocations.
This seemed like a good way to kick the tires on the
elided-lifetimes-in-paths lint (#52069)—seems to work! This was also
pretty tedious—it sure would be nice if `cargo fix` worked on this
codebase (#53896)!
refactor match guard
This is the first step to implement RFC 2294: if-let-guard. Tracking issue: https://github.com/rust-lang/rust/issues/51114
The second step should be introducing another variant `IfLet` in the Guard enum. I separated them into 2 PRs for the convenience of reviewers.
r? @petrochenkov
It was pointed out in review that the glob-exported
underscore-suffixed convention for `Spanned` HIR nodes is no longer
preferred: see February 2016's #31487 for AST's migration away from
this style towards properly namespaced NodeKind enums.
This concerns #51968.
There are at least a couple (and plausibly even three) diagnostics that
could use the spans of visibility modifiers in order to be reliably
correct (rather than hacking and munging surrounding spans to try to
infer where the visibility keyword must have been).
We follow the naming convention established by the other `Spanned` HIR
nodes: the "outer" type alias gets the "prime" node-type name, the
"inner" enum gets the name suffixed with an underscore, and the variant
names are prefixed with the prime name and `pub use` exported from here
(from HIR).
Thanks to veteran reviewer Vadim Petrochenkov for suggesting this
uniform approach. (A previous draft, based on the reasoning that
`Visibility::Inherited` should not have a span, tried to hack in a named
`span` field on `Visibility::Restricted` and a positional field on
`Public` and `Crate`. This was ... not so uniform.)
Namely: labels, type parameters, bindings in patterns, parameter names in functions without body.
All of these do not need hygiene after lowering to HIR, only span locations.
Rename hir::ExprAgain to hir::ExprContinue
The current name is confusing and historical.
I also used this PR to clean up the annoying indentation in `check/mod.rs`. If that's viewed as too tangential a change, I'll split it up, but it seemed reasonable to slip it in to reduce @bors's work. It's easy to compare for the two commits individually.
r? @petrochenkov
This is gated on edition 2018 & the `async_await` feature gate.
The parser will accept `async fn` and `async unsafe fn` as fn
items. Along the same lines as `const fn`, only `async unsafe fn`
is permitted, not `unsafe async fn`.The parser will not accept
`async` functions as trait methods.
To do a little code clean up, four fields of the function type
struct have been merged into the new `FnHeader` struct: constness,
asyncness, unsafety, and ABI.
Also, a small bug in HIR printing is fixed: it previously printed
`const unsafe fn` as `unsafe const fn`, which is grammatically
incorrect.
