This applies the HIR changes from the previous commits to the AST, and
is thus a syntax-[breaking-change]
Renames `PatKind::Vec` to `PatKind::Slice`, since these are called slice
patterns, not vec patterns. Renames `TyKind::Vec`, which represents the
type `[T]`, to `TyKind::Slice`. Renames `TyKind::FixedLengthVec` to
`TyKind::Array`.
Adds a `ProcMacro` form of syntax extension
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Note that RFC #1566 has not been accepted yet, but I think there is consensus that we want to head in vaguely that direction and so this PR will be useful in any case. It is also fairly easy to undo and does not break any existing programs.
This is related to #35957 in that I hope it can be used in the implementation of macros 1.1, however, there is no direct overlap and is more of a complement than a competing proposal. There is still a fair bit of work to do before the two can be combined.
r? @jseyfried
cc @alexcrichton, @cgswords, @eddyb, @aturon
This commit adds syntax extension forms matching the types for procedural macros 2.0 (RFC #1566), these still require the usual syntax extension boiler plate, but this is a first step towards proper implementation and should be useful for macros 1.1 stuff too.
Supports both attribute-like and function-like macros.
Optimize the parser's last token handling.
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
Overhaul char_lit()
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`. The error-handling strategy is based on the one used
by byte_lit().
Avoid loading and parsing unconfigured non-inline modules.
For example, `#[cfg(any())] mod foo;` will always compile after this PR, even if `foo.rs` and `foo/mod.rs` do not exist or do not contain valid Rust.
Fixes#36478 and fixes#27873.
r? @nrc
The parser currently makes a heap copy of the last token in four cases:
identifiers, paths, doc comments, and commas. The identifier and
interpolation cases are unused, and for doc comments and commas we only
need to record their presence, not their value.
This commit consolidates the last token handling and avoids the
unnecessary copies by replacing `last_token`, `last_token_eof`, and
`last_token_interpolated` with a new field `last_token_kind`. This
simplifies the parser slightly and speeds up parsing on some files by
3--4%.
This commit does the following.
- Removes parsing support for '\X12', '\u123456' and '\U12345678' char
literals. These are no longer valid Rust and rejected by the lexer.
(This strange-sounding situation occurs because the parser rescans
char literals to compute their value.)
- Rearranges the function so that all the escaped values are handled in
a single `match`, and changes the error-handling to use vanilla
assert!() and unwrap().
This reduces the time taken to run
`rustc -Zparse-only rustc-benchmarks/issue-32278-big-array-of-strings`
from 0.18s to 0.15s on my machine, and reduces the number of
instructions (as measured by Cachegrind) from 1.34B to 1.01B.
With the change applied, the time to fully compile that benchmark is
1.96s, so this is a 1.5% improvement.
Refactor `PathListItem`s
This refactors away variant `Mod` of `ast::PathListItemKind` and refactors the remaining variant `Ident` to a struct `ast::PathListItem_`.
We want to catch this error:
```
if (foo)
bar;
```
as it's valid syntax in other languages, and say how to fix it.
Unfortunately it didn't care if the suggestion made sense and just
highlighted the unexpected token.
Now it attempts to parse a statement, and if it succeeds, it shows the
help message.
Fixes#35907
Specific error message for missplaced doc comments
Identify when documetation comments have been missplaced in the following places:
* After a struct element:
```rust
// file.rs:
struct X {
a: u8 /** document a */,
}
```
```bash
$ rustc file.rs
file.rs:2:11: 2:28 error: found documentation comment that doesn't
document anything
file.rs:2 a: u8 /** document a */,
^~~~~~~~~~~~~~~~~
file.rs:2:11: 2:28 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a struct:
```rust
// file.rs:
struct X {
a: u8,
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
* As the last line of a `fn`:
```rust
// file.rs:
fn main() {
let x = 1;
/// incorrect documentation
}
```
```bash
$ rustc file.rs
file.rs:3:5: 3:27 error: found a documentation comment that doesn't
document anything
file.rs:3 /// incorrect documentation
^~~~~~~~~~~~~~~~~~~~~~
file.rs:3:5: 3:27 help: doc comments must come before what they document,
maybe a comment was intended with `//`?
```
Fix#27429, #30322
Implement the `!` type
This implements the never type (`!`) and hides it behind the feature gate `#[feature(never_type)]`. With the feature gate off, things should build as normal (although some error messages may be different). With the gate on, `!` is usable as a type and diverging type variables (ie. types that are unconstrained by anything in the code) will default to `!` instead of `()`.
Jonas Schievink