Modify message for keyword as identifier name
This is a temporary solution to #46311.
The message is generic enough to cover both cases and is probably a fine enough solution to the specific problem described in the task. However, the underlying reason for this to be wrong is that `next_token_inner` returns `Lifetime` even if the token is a label. That's not simple, as the syntax for both can be quite similar and it may need to take a look to the next token to make a decision. I'm not sure I have enough knowledge about the project to be able to solve that (yet!), so I thought I'll fix the immediate problem first.
Add case insensitive comparison, besides Levenstein for DYM
Closes#46332
Draft version. The idea is that Levenstein does not work for some cases when we have multiple equal weights for strings. I didn't understand the case with `if found != name => Some(found)` so it means that new code does not work correctly yet.
At least now I think that we might return all maximal weights from levenstein and think about next cases in priority order:
1) There is exact match -> None
2) There is exact match, but case insensitive -> Some(match)
3) There is some match from levenstein -> Some(matches.take_any)
4) There is no match -> None
@estebank WDYT?
Generic Associated Types Parsing & Name Resolution
Hi!
This PR adds parsing for generic associated types! 🎉🎉🎉
Tracking Issue: #44265
## Notes For Reviewers
* [x] I still need to add the stdout and stderr files to my ui tests. It takes me a *long* time to compile the compiler locally, so I'm going to add this as soon as possible in the next day or so.
* [ ] My current ui tests aren't very good or very thorough. I'm reusing the `parse_generics` and `parse_where_clause` methods from elsewhere in the parser, so my changes work without being particularly complex. I'm not sure if I should duplicate all of the generics test cases for generic associated types. It might actually be appropriate to duplicate everything here, since we don't want to rely on an implementation detail in case it changes in the future. If you think so too, I'll adapt all of the generics test cases into the generic associated types test cases.
* [ ] There is still more work required to make the run-pass tests pass here. In particular, we need to make the following errors disappear:
```
error[E0110]: lifetime parameters are not allowed on this type
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:23:41
|
23 | bar: <T as StreamingIterator>::Item<'static>,
| ^^^^^^^ lifetime parameter not allowed on this type
```
```
error[E0261]: use of undeclared lifetime name `'a`
--> ./src/test/run-pass/rfc1598-generic-associated-types/iterable.rs:15:47
|
15 | type Iter<'a>: Iterator<Item = Self::Item<'a>>;
| ^^ undeclared lifetime
```
There is a FIXME comment in streaming_iterator. If you uncomment that line, you get the following:
```
error: expected one of `!`, `+`, `,`, `::`, or `>`, found `=`
--> ./src/test/run-pass/rfc1598-generic-associated-types/streaming_iterator.rs:29:45
|
29 | fn foo<T: for<'a> StreamingIterator<Item<'a>=&'a [i32]>>(iter: T) { /* ... */ }
| ^ expected one of `!`, `+`, `,`, `::`, or `>` here
```
r? @nikomatsakis
The previous method ran into problems because ICH would treat Spans
as (file,line,col) but the cache contained byte offsets and its
possible for the latter to change while the former stayed stable.
Remove semicolon note
In reference to issue #46186
r? @estebank
First time doing a pull request, if there are any suggestions on how to improve this please let me know.
@jjolly
When encountering `pub ident`, attempt to identify the code that comes
afterwards, wether it is a brace block (assume it is a struct), a paren
list followed by a colon (assume struct) or a paren list followed by a
block (assume a fn). Consume those blocks to avoid any further parser
errors and return a `Placeholder` item in order to allow the parser to
continue. In the case of unenclosed blocks, the behavior is the same as
it is currently: no further errors are processed.
rustdoc: include external files in documentation (RFC 1990)
Part of https://github.com/rust-lang/rfcs/pull/1990 (needs work on the error reporting, which i'm deferring to after this initial PR)
cc #44732
Also fixes#42760, because the prep work for the error reporting made it easy to fix that at the same time.
show macro backtrace with -Z flag
Fixes#39413 by adding a facility to restore the "old school" macro expansion backtraces (previously removed in 61865384b8).
The restored functionality is accessed through the flag `-Z external-macro-backtrace`. Errors showing the truncated backtraces will suggest this flag.
### Example
Code: <details>
`a/src/lib.rs`
```rust
#[macro_export]
macro_rules! a {
() => { a!(@) };
(@) => { a!(@@) };
(@@) => {
syntax error;
}
}
```
`b/src/main.rs`
```rust
#[macro_use] extern crate a;
macro_rules! b {
() => { b!(@) };
(@) => { b!(@@) };
(@@) => {
syntax error;
}
}
fn main() {
a!();
b!();
}
```
</details>
<br/><br/>
Running without env var (note: first error is from remote macro, second from local macro):
<details>
```
$ cargo +custom run
Compiling b v0.1.0
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
--> src/main.rs:12:5
|
12 | a!();
| ^^^^^
| |
| expected one of 8 possible tokens here
| unexpected token
|
= note: this error originates in a macro outside of the current crate (run with RUST_MACRO_BACKTRACE=1 for more info)
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
--> src/main.rs:7:16
|
7 | syntax error;
| -^^^^^ unexpected token
| |
| expected one of 8 possible tokens here
...
13 | b!();
| ----- in this macro invocation
error: aborting due to 2 previous errors
error: Could not compile `b`.
To learn more, run the command again with --verbose.
```
</details>
The output is the same as today, except for an addition to the note which aids discoverability of the new environment variable.
<br/><br/>
Running _with_ env var:
<details>
```
$ RUST_MACRO_BACKTRACE=1 cargo +custom run
Compiling b v0.1.0
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
--> <a macros>:1:72
|
1 | ( ) => { a ! ( @ ) } ; ( @ ) => { a ! ( @ @ ) } ; ( @ @ ) => { syntax error ;
| -^^^^^ unexpected token
| |
| expected one of 8 possible tokens here
src/main.rs:12:5: 12:10 note: in this expansion of a! (defined in <a macros>)
<a macros>:1:11: 1:20 note: in this expansion of a! (defined in <a macros>)
<a macros>:1:36: 1:47 note: in this expansion of a! (defined in <a macros>)
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
--> src/main.rs:7:16
|
7 | syntax error;
| -^^^^^ unexpected token
| |
| expected one of 8 possible tokens here
src/main.rs:12:5: 12:10 note: in this expansion of a! (defined in <a macros>)
<a macros>:1:11: 1:20 note: in this expansion of a! (defined in <a macros>)
<a macros>:1:36: 1:47 note: in this expansion of a! (defined in <a macros>)
error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `error`
--> src/main.rs:7:16
|
7 | syntax error;
| -^^^^^ unexpected token
| |
| expected one of 8 possible tokens here
src/main.rs:13:5: 13:10 note: in this expansion of b! (defined in src/main.rs)
src/main.rs:4:13: 4:18 note: in this expansion of b! (defined in src/main.rs)
src/main.rs:5:14: 5:20 note: in this expansion of b! (defined in src/main.rs)
error: aborting due to 2 previous errors
error: Could not compile `b`.
To learn more, run the command again with --verbose.
```
</details>
The output is hard to read, but better than nothing (and it's exactly what we used to have before the infamous `fix_multispans_in_std_macros`).
<br/><br/>
Wishlist:
- Save the actual source of macros in crate metadata, not just AST, so the output can be improved
- Hopefully this would allow line numbers in the trace as well
- Show the actual macro invocations in the traces
r? @nrc
show in docs whether the return type of a function impls Iterator/Read/Write
Closes#25928
This PR makes it so that when rustdoc documents a function, it checks the return type to see whether it implements a handful of specific traits. If so, it will print the impl and any associated types. Rather than doing this via a whitelist within rustdoc, i chose to do this by a new `#[doc]` attribute parameter, so things like `Future` could tap into this if desired.
### Known shortcomings
~~The printing of impls currently uses the `where` class over the whole thing to shrink the font size relative to the function definition itself. Naturally, when the impl has a where clause of its own, it gets shrunken even further:~~ (This is no longer a problem because the design changed and rendered this concern moot.)
The lookup currently just looks at the top-level type, not looking inside things like Result or Option, which renders the spotlights on Read/Write a little less useful:
<details><summary>`File::{open, create}` don't have spotlight info (pic of old design)</summary>
</details>
All three of the initially spotlighted traits are generically implemented on `&mut` references. Rustdoc currently treats a `&mut T` reference-to-a-generic as an impl on the reference primitive itself. `&mut Self` counts as a generic in the eyes of rustdoc. All this combines to create this lovely scene on `Iterator::by_ref`:
<details><summary>`Iterator::by_ref` spotlights Iterator, Read, and Write (pic of old design)</summary>
</details>
