expand: Leave traces when expanding `cfg` attributes
This is the same as https://github.com/rust-lang/rust/pull/138515, but for `cfg(true)` instead of `cfg_attr`.
The difference is that `cfg(true)`s already left "traces" after themselves - the `cfg` attributes themselves, with `expanded_inert_attrs` set to true, with full tokens, available to proc macros.
This is not a reasonably expected behavior, but it could not be removed without a replacement, because a [major rustdoc feature](https://github.com/rust-lang/rfcs/pull/3631) and a number of clippy lints rely on it. This PR implements a replacement.
This needs a crater run, because it changes observable behavior (in an intended way) - proc macros can no longer see expanded `cfg(true)` attributes.
(Some minor unnecessary special casing for `sym::cfg_attr` is also removed in this PR.)
r? `@nnethercote`
Mostly parser: Eliminate code that's been dead / semi-dead since the removal of type ascription syntax
**Disclaimer**: This PR is intended to mostly clean up code as opposed to bringing about behavioral changes. Therefore it doesn't aim to address any of the 'FIXME: remove after a month [dated: 2023-05-02]: "type ascription syntax has been removed, see issue [#]101728"'.
---
By commit:
1. Removes truly dead code:
* Since 1.71 (#109128) `let _ = { f: x };` is a syntax error as opposed to a semantic error which allows the parse-time diagnostic (suggestion) "*struct literal body without path // you might have forgotten […]*" to kick in.
* The analysis-time diagnostic (suggestion) from <=1.70 "*cannot find value \`f\` in this scope // you might have forgotten […]*" is therefore no longer reachable.
2. Updates `is_certainly_not_a_block` to be in line with the current grammar:
* The seq. `{ ident:` is definitely not the start of a block. Before the removal of ty ascr, `{ ident: ty_start` would begin a block expr.
* This shouldn't make more code compile IINM, it should *ultimately* only affect diagnostics.
* For example, `if T { f: () } {}` will now be interpreted as an `if` with struct lit `T { f: () }` as its *condition* (which is banned in the parser anyway) as opposed to just `T` (with the *consequent* being `f : ()` which is also invalid (since 1.71)). The diagnostics are almost the same because we have two separate parse recovery procedures + diagnostics: `StructLiteralNeedingParens` (*invalid struct lit*) before and `StructLiteralNotAllowedHere` (*struct lits aren't allowed here*) now, as you can see from the diff.
* (As an aside, even before this PR, fn `maybe_suggest_struct_literal` should've just used the much older & clearer `StructLiteralNotAllowedHere`)
* NB: This does sadly regress the compiler output for `tests/ui/parser/type-ascription-in-pattern.rs` but that can be fixed in follow-up PRs. It's not super important IMO and a natural consequence.
3. Removes code that's become dead due to the prior commit.
* Basically reverts #106620 + #112475 (without regressing rustc's output!).
* Now the older & more robust parse recovery procedure (cc `StructLiteralNotAllowedHere`) takes care of the cases the removed code used to handle.
* This automatically fixes the suggestions for \[[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=7e2030163b11ee96d17adc3325b01780)\]:
* `if Ty::<i32> { f: K }.m() {}`: `if Ty::<i32> { SomeStruct { f: K } }.m() {}` (broken) → ` if (Ty::<i32> { f: K }).m() {}`
* `if <T as Trait>::Out { f: K::<> }.m() {}`: `if <T as Trait>(::Out { f: K::<> }).m() {}` (broken) → `if (<T as Trait>::Out { f: K::<> }).m() {}`
4. Merge and simplify UI tests pertaining to this issue, so it's easier to add more regression tests like for the two cases mentioned above.
5. Merge UI tests and add the two regression tests.
Best reviewed commit by commit (on request I'll partially squash after approval).
On long spans, trim the middle of them to make them fit in the terminal width
When encountering a single line span that is wider than the terminal, we keep context at the start and end of the span but otherwise remove the code from the middle. This is somewhat independent from whether the left and right margins of the output have been trimmed as well.
```
error[E0308]: mismatched types
--> $DIR/long-span.rs:6:15
|
LL | ... = [0, 0, 0, 0, ..., 0, 0];
| ^^^^^^^^^^^^^...^^^^^^^ expected `u8`, found `[{integer}; 1681]`
```
Address part of https://github.com/rust-lang/rust/issues/137680 (missing handling of the long suggestion). Fix https://github.com/rust-lang/rust/issues/125581.
---
Change the way that underline positions are calculated by delaying using the "visual" column position until the last possible moment, instead using the "file"/byte position in the file, and then calculating visual positioning as late as possible. This should make the underlines more resilient to non-1-width unicode chars.
Unfortunately, as part of this change (which fixes some visual bugs) comes with the loss of some eager tab codepoint handling, but the output remains legible despite some minor regression on the "margin trimming" logic.
---
`-Zteach` is perma-unstable, barely used, the highlighting logic buggy and the flag being passed around is tech-debt. We should likely remove `-Zteach` in its entirely.
Change the way that underline positions are calculated by delaying using
the "visual" column position until the last possible moment, instead
using the "file"/byte position in the file, and then calculating visual
positioning as late as possible. This should make the underlines more
resilient to non-1-width unicode chars.
Unfortunately, as part of this change (which fixes some visual bugs)
comes with the loss of some eager tab codepoint handling, but the output
remains legible despite some minor regression on the "margin trimming"
logic.
When encountering a single line span that is wider than the terminal, we keep context at the start and end of the span but otherwise remove the code from the middle. This is somewhat independent from whether the left and right margins of the output have been trimmed as well.
```
error[E0308]: mismatched types
--> $DIR/long-span.rs:6:15
|
LL | ... = [0, 0, 0, 0, ..., 0, 0];
| ^^^^^^^^^^^^^...^^^^^^^ expected `u8`, found `[{integer}; 1681]`
```
Address part of #137680 (missing handling of the long suggestion). Fix#125581.
Note: there was an existing code path involving `Interpolated` in
`MetaItem::from_tokens` that was dead. This commit transfers that to the
new form, but puts an `unreachable!` call inside it.
The one notable test change is `tests/ui/macros/trace_faulty_macros.rs`.
This commit removes the complicated `Interpolated` handling in
`expected_expression_found` that results in a longer error message. But
I think the new, shorter message is actually an improvement.
The original complaint was in #71039, when the error message started
with "error: expected expression, found `1 + 1`". That was confusing
because `1 + 1` is an expression. Other than that, the reporter said
"the whole error message is not too bad if you ignore the first line".
Subsequently, extra complexity and wording was added to the error
message. But I don't think the extra wording actually helps all that
much. In particular, it still says of the `1+1` that "this is expected
to be expression". This repeats the problem from the original complaint!
This commit removes the extra complexity, reverting to a simpler error
message. This is primarily because the traversal is a pain without
`Interpolated` tokens. Nonetheless, I think the error message is
*improved*. It now starts with "expected expression, found `pat`
metavariable", which is much clearer and the real problem. It also
doesn't say anything specific about `1+1`, which is good, because the
`1+1` isn't really relevant to the error -- it's the `$e:pat` that's
important.
```
error[E0614]: type `(..., ..., ..., ...)` cannot be dereferenced
--> $DIR/long-E0614.rs:10:5
|
LL | *x;
| ^^ can't be dereferenced
|
= note: the full name for the type has been written to '$TEST_BUILD_DIR/$FILE.long-type-hash.txt'
= note: consider using `--verbose` to print the full type name to the console
```
Fix "missing match arm body" suggestion involving `!`
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
r? `@compiler-errors`
Include the match arm guard in the gated span, so that the suggestion to add a body is correct instead of inserting the body before the guard.
Make the suggestion verbose.
```
error: `match` arm with no body
--> $DIR/feature-gate-never_patterns.rs:43:9
|
LL | Some(_) if false,
| ^^^^^^^^^^^^^^^^
|
help: add a body after the pattern
|
LL | Some(_) if false => { todo!() },
| ++++++++++++++
```
Ferris 🦀 Identifier naming conventions
You cannot use Ferris as an identifier in Rust, this code will suggest to correct the 🦀 to `ferris`:
```rs
fn main() {
let 🦀 = 4;
}
```
But it also suggests to correct to `ferris` in these cases, too:
```rs
struct 🦀 {}
fn main() {}
```
^ suggests: `ferris`
~ with this PR: `Ferris`
```rs
static 🦀: &str = "ferris!";
fn main() {}
```
^ suggests: `ferris`
~ with this PR: `FERRIS`
This is my first pull requests here!
Remove `NtVis` and `NtTy`
The next part of #124141. The first actual remove of `Nonterminal` variants. `NtVis` is a simple case that doesn't get much use, but `NtTy` is more complex.
r? `@petrochenkov`
Notes about tests:
- tests/ui/parser/macro/trait-object-macro-matcher.rs: the syntax error
is duplicated, because it occurs now when parsing the decl macro
input, and also when parsing the expanded decl macro. But this won't
show up for normal users due to error de-duplication.
- tests/ui/associated-consts/issue-93835.rs: similar, plus there are
some additional errors about this very broken code.
- The changes to metavariable descriptions in #132629 are now visible in
error message for several tests.
Tweak "expected ident" parse error to avoid talking about doc comments
When encountering a doc comment without an identifier after, we'd unconditionally state "this doc comment doesn't document anything", swallowing the *actual* error which is that the thing *after* the doc comment wasn't expected. Added a check that the found token is something that "conceptually" closes the previous item before emitting that error, otherwise just complain about the missing identifier.
In both of the following cases, the syntax error follows a doc comment:
```
error: expected identifier, found keyword `Self`
--> $DIR/doc-before-bad-variant.rs:4:5
|
LL | enum TestEnum {
| -------- while parsing this enum
...
LL | Self,
| ^^^^ expected identifier, found keyword
|
= help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }`
```
```
error: expected identifier, found `<`
--> $DIR/doc-before-syntax-error.rs:2:1
|
LL | <>
| ^ expected identifier
```
Fix#71982.
When encountering a doc comment without an identifier after, we'd unconditionally state "this doc comment doesn't document anything", swallowing the *actual* error which is that the thing *after* the doc comment wasn't expected. Added a check that the found token is something that "conceptually" closes the previous item before emitting that error, otherwise just complain about the missing identifier.
In both of the following cases, the syntax error follows a doc comment:
```
error: expected identifier, found keyword `Self`
--> $DIR/doc-before-bad-variant.rs:4:5
|
LL | enum TestEnum {
| -------- while parsing this enum
...
LL | Self,
| ^^^^ expected identifier, found keyword
|
= help: enum variants can be `Variant`, `Variant = <integer>`, `Variant(Type, ..., TypeN)` or `Variant { fields: Types }`
```
```
error: expected identifier, found `<`
--> $DIR/doc-before-syntax-error.rs:2:1
|
LL | <>
| ^ expected identifier
```
Fix#71982.
Because of an ambiguity with const closures, the parser needs to ensure
that for a const item, the `const` keyword isn't followed by a `move` or
`static` keyword, as that would indicate a const closure:
```rust
fn main() {
const move // ...
}
```
This check did not take raw identifiers into account, therefore being
unable to distinguish between `const move` and `const r#move`. The
latter is obviously not a const closure, so it should be allowed as a
const item.
This fixes the check in the parser to only treat `const ...` as a const
closure if it's followed by the *proper keyword*, and not a raw
identifier.
Additionally, this adds a large test that tests for all raw identifiers in
all kinds of positions, including `const`, to prevent issues like this
one from occurring again.
Do not allow attributes on struct field rest patterns
Fixes#81282.
This removes support for attributes on struct field rest patterns (the `..` bit) from the parser. Previously any attributes were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
This needs an equivalent change to the reference but I wanted to see how this PR is received first.
The error message it produces isn't great, however it does match the error you get if you try to add attributes to .. in struct expressions atm, although I can understand wanting to do better given this was previously accepted. I think I could move attribute parsing back up to where it was and then emit a specific new error for this case, however I might need some guidance as this is the first time I've messed around inside the compiler.
While this is technically breaking I don't think it's much of an issue: attributes in this position don't currently do anything and rustfmt outright deletes them, meaning it's incredibly unlikely to affect anyone. I have already made the equivalent change to *add* support for attributes (mostly) but the conversation in the linked issue suggested it would be more reasonable to just remove them (and pointed out it's much easier to add support later if we realise we need them).
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
--> $DIR/attempted-access-non-fatal.rs:7:15
|
LL | let _ = 2.l;
| ^
|
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
|
LL - let _ = 2.l;
LL + let _ = 2.0f64;
|
```
This removes support for attributes on struct field rest patterns (the `..`) from the parser.
Previously they were being parsed but dropped from the AST, so didn't work and were deleted by rustfmt.
Trim extra whitespace when suggesting removal of invalid qualifiers when
parsing function pointer type.
Fixes: #133083
Signed-off-by: Tyrone Wu <wudevelops@gmail.com>
Reword resolve errors caused by likely missing crate in dep tree
Reword label and add `help`:
```
error[E0432]: unresolved import `some_novel_crate`
--> f704.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
|
= help: if you wanted to use a crate named `some_novel_crate`, use `cargo add some_novel_crate` to add it to your `Cargo.toml`
```
Fix#133137.
```
error[E0432]: unresolved import `some_novel_crate`
--> file.rs:1:5
|
1 | use some_novel_crate::Type;
| ^^^^^^^^^^^^^^^^ use of unresolved module or unlinked crate `some_novel_crate`
```
On resolve errors where there might be a missing crate, mention `cargo add foo`:
```
error[E0433]: failed to resolve: use of unresolved module or unlinked crate `nope`
--> $DIR/conflicting-impl-with-err.rs:4:11
|
LL | impl From<nope::Thing> for Error {
| ^^^^ use of unresolved module or unlinked crate `nope`
|
= help: if you wanted to use a crate named `nope`, use `cargo add nope` to add it to your `Cargo.toml`
```
Point at invalid utf-8 span on user's source code
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: byte `193` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix#76869.
Properly record metavar spans for other expansions other than TT
This properly records metavar spans for nonterminals other than tokentree. This means that we operations like `span.to(other_span)` work correctly for macros. As you can see, other diagnostics involving metavars have improved as a result.
Fixes#132908
Alternative to #133270
cc `@ehuss`
cc `@petrochenkov`
```
error: couldn't read `$DIR/not-utf8-bin-file.rs`: stream did not contain valid UTF-8
--> $DIR/not-utf8-2.rs:6:5
|
LL | include!("not-utf8-bin-file.rs");
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: `[193]` is not valid utf-8
--> $DIR/not-utf8-bin-file.rs:2:14
|
LL | let _ = "�|�␂!5�cc␕␂��";
| ^
= note: this error originates in the macro `include` (in Nightly builds, run with -Z macro-backtrace for more info)
```
When we attempt to load a Rust source code file, if there is a OS file failure we try reading the file as bytes. If that succeeds we try to turn it into UTF-8. If *that* fails, we provide additional context about *where* the file has the first invalid UTF-8 character.
Fix#76869.
rustc_intrinsic: support functions without body
We synthesize a HIR body `loop {}` but such bodyless intrinsics.
Most of the diff is due to turning `ItemKind::Fn` into a brace (named-field) enum variant, because it carries a `bool`-typed field now. This is to remember whether the function has a body. MIR building panics to avoid ever translating the fake `loop {}` body, and the intrinsic logic uses the lack of a body to implicitly mark that intrinsic as must-be-overridden.
I first tried actually having no body rather than generating the fake body, but there's a *lot* of code that assumes that all function items have HIR and MIR, so this didn't work very well. Then I noticed that even `rustc_intrinsic_must_be_overridden` intrinsics have MIR generated (they are filled with an `Unreachable` terminator) so I guess I am not the first to discover this. ;)
r? `@oli-obk`
