Attach tokens to all AST types used in `Nonterminal`
We perform token capturing when we have outer attributes (for nonterminals that support attributes - e.g. `Stmt`), or when we parse a `Nonterminal` for a `macro_rules!` argument. The full list of `Nonterminals` affected by this PR is:
* `NtBlock`
* `NtStmt`
* `NtTy`
* `NtMeta`
* `NtPath`
* `NtVis`
* `NtLiteral`
Of these nonterminals, only `NtStmt` and `NtLiteral` (which is actually just an `Expr`), support outer attributes - the rest only ever have token capturing perform when they match a `macro_rules!` argument.
This makes progress towards solving https://github.com/rust-lang/rust/issues/43081 - we now collect tokens for everything that might need them. However, we still need to handle `#[cfg]`, inner attributes, and misc pretty-printing issues (e.g. #75734)
I've separated the changes into (mostly) independent commits, which could be split into individual PRs for each `Nonterminal` variant. The purpose of having them all in one PR is to do a single Crater run for all of them.
Most of the changes in this PR are trivial (adding `tokens: None` everywhere we construct the various AST structs). The significant changes are:
* `ast::Visibility` is changed from `type Visibility = Spanned<VisibilityKind>` to a `struct Visibility { kind, span, tokens }`.
* `maybe_collect_tokens` is made generic, and used for both `ast::Expr` and `ast::Stmt`.
* Some of the statement-parsing functions are refactored so that we can capture the trailing semicolon.
* `Nonterminal` and `Expr` both grew by 8 bytes, as some of the structs which are stored inline (rather than behind a `P`) now have an `Option<TokenStream>` field. Hopefully the performance impact of doing this is negligible.
BTreeMap: move up reference to map's root from NodeRef
Since the introduction of `NodeRef` years ago, it also contained a mutable reference to the owner of the root node of the tree (somewhat disguised as *const). Its intent is to be used only when the rest of the `NodeRef` is no longer needed. Moving this to where it's actually used, thought me 2 things:
- Some sort of "postponed mutable reference" is required in most places that it is/was used, and that's exactly where we also need to store a reference to the length (number of elements) of the tree, for the same reason. The length reference can be a normal reference, because the tree code does not care about tree length (just length per node).
- It's downright obfuscation in `from_sorted_iter` (transplanted to #75329)
- It's one of the reasons for the scary notice on `reborrow_mut`, the other one being addressed in #73971.
This does repeat the raw pointer code in a few places, but it could be bundled up with the length reference.
r? `@Mark-Simulacrum`
We currently only attach tokens when parsing a `:stmt` matcher for a
`macro_rules!` macro. Proc-macro attributes on statements are still
unstable, and need additional work.
add the `const_evaluatable_checked` feature
Implements a rather small subset of https://github.com/rust-lang/compiler-team/issues/340
Unlike the MCP, this does not try to compare different constant, but instead only adds the constants found in where clauses
to the predicates of a function. This PR adds the feature gate `const_evaluatable_checked`, without which nothing should change.
r? @oli-obk @eddyb
Reword `trivial_casts` lint in rustc book to better explain what it does.
The current description of the trivial casts lint under the "allowed
by default" listing in the rustc book indicates the lint is for casts
which may be removed, which is less clear than saying it's for casts
which may be replaced by coercion (which is the wording used by the
error message included in the doc).
This commit changes the wording slightly to better describe what the
lint does.
This issue bit me in some recent code where I was attempting to
convert a `Vec<SomeType>` to a `Vec<SomeTraitObject>`, and
hit my project-wide `#![deny(trivial_casts)]` with
`map(|o| Box::new(o) as TraitObject)`. I'd read the book docs for
`trivial_casts` and was surprised by the error, as I took it to mean
the cast ought to be removed (rather than replaced by ascription
in this case). Removing the cast meant other code didn't compile,
and I then found issues like #23742 and realized my misunderstanding.
Validate removal of AscribeUserType, FakeRead, and Shallow borrow
Those statements are removed by CleanupNonCodegenStatements pass
in drop lowering phase, and should not occur afterwards.
typeck: don't suggest inaccessible private fields
Fixes#76077.
This PR adjusts the missing field diagnostic logic in typeck so that when none of the missing fields in a struct expr are accessible then the error is less confusing.
r? @estebank
Add revisions to const generic issue UI tests.
Fixes#75279.
I have gotten into the flow, so I can do more of these if requested. I'm looking for feedback as to whether my work is on the right track so far.
Syntactically permit unsafety on mods
Similar to https://github.com/rust-lang/rust/pull/66183; we will accept these constructs syntactically but reject with a semantic check after macro expansion if a proc macro hasn't replaced it with something else meaningful to Rust.
```rust
#[mymacro]
unsafe mod m {
...
}
#[mymacro]
unsafe extern "C++" {
...
}
```
The intention is that this might be used as a kind of "item-level unsafe" in attribute macro DSLs -- holding things which are unsafe to declare but potentially safe to use. For example I look forward to using this in https://github.com/dtolnay/cxx.
In the absence of a procedural macro rewriting them to something else, they'll continue to be rejected at compile time though with a better error message than before.
### Before:
```console
error: expected item, found keyword `unsafe`
--> src/main.rs:1:1
|
1 | unsafe mod m {
| ^^^^^^ expected item
```
### After:
```console
error: module cannot be declared unsafe
--> src/main.rs:1:1
|
1 | unsafe mod m {
| ^^^^^^
error: extern block cannot be declared unsafe
--> src/main.rs:4:1
|
4 | unsafe extern "C++" {
| ^^^^^^
```
Closes#68048.
This commit adjusts the missing field diagnostic logic for struct
patterns in typeck to improve the diagnostic when the missing fields are
inaccessible.
Signed-off-by: David Wood <david@davidtw.co>
This commit adjusts the missing field diagnostic logic for struct
expressions in typeck to improve the diagnostic when the missing
fields are inaccessible.
Signed-off-by: David Wood <david@davidtw.co>
ci: avoid moving the build directory on GHA
While waiting for a PR job to start testing my code, I noticed the symlink-build-dir step took 10 minutes to complete, so I investigated what caused that.
It seems like something changed in the build environment between version 20200901.1 (where the step took 45 seconds) and version 20200908.1 (where the step took 10 minutes). At the time of writing this commit, the rust-lang organization is on vertsion 20200908.1, while the rust-lang-ci organization is at version 20200901.1 (and is not affected by this yet).
There is no need for this step anymore on GHA, as our XL builders got an increase in the root paritition size, so this commit removes the code that moved stuff around on GHA (while keeping it on Azure).
For the record, at the time of writing this, the disk situation is:
```
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 667G 60G 607G 9% /
/dev/sdb1 110G 4.1G 101G 4% /mnt
```
r? `@Mark-Simulacrum`
improve the suggestion of the lint `unit-arg`
Fixes#5823Fixes#6015
Changes
```
help: move the expression in front of the call...
|
3 | g();
|
help: ...and use a unit literal instead
|
3 | o.map_or((), |i| f(i))
|
```
into
```
help: move the expression in front of the call and replace it with the unit literal `()`
|
3 | g();
| o.map_or((), |i| f(i))
|
```
changelog: improve the suggestion of the lint `unit-arg`
While waiting for a PR job to start testing my code, I noticed the
symlink-build-dir step took 10 minutes to complete, so I investigated
what caused that.
It seems like something changed in the build environment between version
20200901.1 (where the step took 45 seconds) and version 20200908.1
(where the step took 10 minutes). At the time of writing this commit,
the rust-lang organization is on vertsion 20200908.1, while the
rust-lang-ci organization is at version 20200901.1 (and is not affected
by this yet).
There is no need for this step anymore on GHA, as our XL builders got an
increase in the root paritition size, so this commit removes the code
that moved stuff around on GHA (while keeping it on Azure).
For the record, at the time of writing this, the disk situation is:
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 667G 60G 607G 9% /
/dev/sdb1 110G 4.1G 101G 4% /mnt
rustbuild: Build tests with LLD if `use-lld = true` was passed
Addresses https://github.com/rust-lang/rust/pull/76127#discussion_r479932392.
Our test suite is generally ready to run with an explicitly specified linker (https://github.com/rust-lang/rust/pull/45191),
so LLD specified with `use-lld = true` works as well.
Only 4 tests fail (on `x86_64-pc-windows-msvc`):
```
ui/panic-runtime/lto-unwind.rs
run-make-fulldeps/debug-assertions
run-make-fulldeps/foreign-exceptions
run-make-fulldeps/test-harness
```
All of them are legitimate issues with LLD (or at least with combination Rust+LLD) and manifest in segfaults on access to TLS (https://github.com/rust-lang/rust/pull/76127#issuecomment-683473325). UPD: These issues are caused by https://github.com/rust-lang/rust/issues/72145 and appear because I had `-Ctarget-cpu=native` set.
UPD: Further commits build tests with LLD for non-MSVC targets and propagate LLD to more places when `use-lld` is enabled.
