| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Move retokenize hack to save_analysis
closes #76046
|
|
|
|
Use smaller def span for functions
Currently, the def span of a function encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}
```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
Re-land PR #72388: Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
PR #72388 allowed us to preserve the original `TokenStream` in more cases during proc-macro expansion, but had to be reverted due to a large number of regressions (See #72545 and #72622). These regressions fell into two categories
1. Missing handling for `Group`s with `Delimiter::None`, which are inserted during `macro_rules!` expansion (but are lost during stringification and re-parsing). A large number of these regressions were due to `syn` and `proc-macro-hack`, but several crates needed changes to their own proc-macro code.
2. Legitimate hygiene issues that were previously being masked by stringification. Some of these were relatively benign (e.g. [a compiliation error](https://github.com/paritytech/parity-scale-codec/pull/210) caused by misusing `quote_spanned!`). However, two crates had intentionally written unhygenic `macro_rules!` macros, which were able to access identifiers that were not passed as arguments (see https://github.com/rust-lang/rust/issues/72622#issuecomment-636402573).
All but one of the Crater regressions have now been fixed upstream (see https://hackmd.io/ItrXWRaSSquVwoJATPx3PQ?both). The remaining crate (which has a PR pending at https://github.com/sammhicks/face-generator/pull/1) is not on `crates.io`, and is a Yew application that seems unlikely to have any reverse dependencies.
As @petrochenkov mentioned in https://github.com/rust-lang/rust/issues/72545#issuecomment-638632434, not re-landing PR #72388 allows more crates to write unhygenic `macro_rules!` macros, which will eventually stop compiling. Since there is only one Crater regression remaining, since additional crates could write unhygenic `macro_rules!` macros in the time it takes that PR to be merged.
|
|
Currently, the def span of a funtion encompasses the entire function
signature and body. However, this is usually unnecessarily verbose - when we are
pointing at an entire function in a diagnostic, we almost always want to
point at the signature. The actual contents of the body tends to be
irrelevant to the diagnostic we are emitting, and just takes up
additional screen space.
This commit changes the `def_span` of all function items (freestanding
functions, `impl`-block methods, and `trait`-block methods) to be the
span of the signature. For example, the function
```rust
pub fn foo<T>(val: T) -> T { val }
```
now has a `def_span` corresponding to `pub fn foo<T>(val: T) -> T`
(everything before the opening curly brace).
Trait methods without a body have a `def_span` which includes the
trailing semicolon. For example:
```rust
trait Foo {
fn bar();
}```
the function definition `Foo::bar` has a `def_span` of `fn bar();`
This makes our diagnostic output much shorter, and emphasizes
information that is relevant to whatever diagnostic we are reporting.
We continue to use the full span (including the body) in a few of
places:
* MIR building uses the full span when building source scopes.
* 'Outlives suggestions' use the full span to sort the diagnostics being
emitted.
* The `#[rustc_on_unimplemented(enclosing_scope="in this scope")]`
attribute points the entire scope body.
* The 'unconditional recursion' lint uses the full span to show
additional context for the recursive call.
All of these cases work only with local items, so we don't need to
add anything extra to crate metadata.
|
|
Fixes #68430
This is a re-attempt of PR #72388, which was previously reverted due to
a large number of breakages. All of the known breakages should now be
patched upstream.
|
|
Gate if-let guard feature
Enhanced on #74315. That PR is in crater queue so I don't want to push to it.
Close #74232
cc #51114
|
|
Move doc comment parsing to rustc_lexer
Plain comments are trivia, while doc comments are not, so it feels
like this belongs to the rustc_lexer.
The specific reason to do this is the desire to use rustc_lexer in
rustdoc for syntax highlighting, without duplicating "is this a doc
comment?" logic there.
r? @ghost
|
|
Capture tokens for Pat used in macro_rules! argument
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
All other tokens are named by the punctuation they use, rather than
by semantics operation they stand for. `!` is the only exception to
the rule, let's fix it.
|
|
This extends PR #73293 to handle patterns (Pat). Unlike expressions,
patterns do not support custom attributes, so we only need to capture
tokens during macro_rules! argument parsing.
|
|
Outer `if` is the fast path -- it calls into hyperoptimized memchr.
The inner loop is just the simplest code possible -- it doesn't
generated the tightest code, but that shouldn't matter if we are going
to error anyhow.
|
|
Plain comments are trivial, while doc comments are not, so it feels
like this belongs to the rustc_lexer.
The specific reason to do this is the desire to use rustc_lexer in
rustdoc for syntax highlighting, without duplicating "is this a doc
comment?" logic there.
|
|
Don't emit "is not a logical operator" error outside of associative expressions
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
---
First time contributor! Let me know if there are any conventions or policies I should be following that I missed here. Thanks :)
|
|
Avoid showing this error where it doesn't make sense by not assuming
"and" and "or" were intended to mean "&&" and "||" until after we decide
to continue parsing input as an associative expression.
Note that the decision of whether or not to continue parsing input as an
associative expression doesn't actually depend on this assumption.
Fixes #75599
|
|
|
|
|
|
Recover gracefully from `struct` parse errors
Currently the parser tries to recover from finding a keyword where a field name was expected, but this causes extra knock down parse errors that are completely irrelevant. Instead, bail out early in the parsing of the field and consume the remaining tokens in the block. This can reduce output significantly.
_Improvements based on the narrative in https://fasterthanli.me/articles/i-am-a-java-csharp-c-or-cplusplus-dev-time-to-do-some-rust_
|
|
|
|
Correctly parse `{} && false` in tail expression
Fix #74233, fix #54186.
|
|
Detect JS-style `===` and `!==` and recover
Fix #75312.
|
|
Fix #75312.
|
|
Detect likely `for foo of bar` JS syntax
Fix #75311.
|
|
Fix #75311.
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #75224 (Don't call a function in function-arguments-naked.rs)
- #75237 (Display elided lifetime for non-reference type in doc)
- #75250 (make MaybeUninit::as_(mut_)ptr const)
- #75253 (clean up const-hacks in int endianess conversion functions)
- #75259 (Add missing backtick)
- #75267 (Small cleanup)
- #75270 (fix a couple of clippy findings)
Failed merges:
r? @ghost
|
|
Small cleanup
* Add docstring to `Parser` field
* Remove unnecessary `unwrap`
* Remove unnecessary borrow
* Fix indentation of some `teach`text output
|
|
Implement the `min_const_generics` feature gate
Implements both https://github.com/rust-lang/lang-team/issues/37 and https://github.com/rust-lang/compiler-team/issues/332.
Adds the new feature gate `#![feature(min_const_generics)]`.
This feature gate adds the following limitations to using const generics:
- generic parameters must only be used in types if they are trivial. (either `N` or `{ N }`)
- generic parameters must be either integers, `bool` or `char`.
We do allow arbitrary expressions in associated consts though, meaning that the following is allowed,
even if `<[u8; 0] as Foo>::ASSOC` is not const evaluatable.
```rust
trait Foo {
const ASSOC: usize;
}
impl<const N: usize> Foo for [u8; N] {
const ASSOC: usize = 64 / N;
}
```
r? @varkor cc @eddyb @withoutboats
|
|
* Add docstring to `Parser` field
* Remove unnecessary `unwrap`
* Remove unnecessary borrow
* Fix indentation of some `teach`text output
|
|
|
|
Beautify all doc strings in rustdoc instead, including those in `#[doc]` attributes
|
|
Explicitly store their kind and style retrieved during lexing in the token
|
|
|
|
Introduce NonterminalKind for more type-safe mbe parsing
It encapsulate the (part of) the interface between the parser and
macro by example (macro_rules) parser.
The second bit is somewhat more general `parse_ast_fragment`, which is
the reason why we keep some `parse_xxx` functions as public.
|
|
Deduplicate `::` -> `:` typo errors
Deduplicate errors caused by the same type ascription typo, including
ones suggested during parsing that would get reported again during
resolve. Fix #70382.
|
|
Seems to be a fallout from rustfmt transition
|
|
It encapsulate the (part of) the interface between the parser and
macro by example (macro_rules) parser.
The second bit is somewhat more general `parse_ast_fragment`, which is
the reason why we keep some `parse_xxx` functions as public.
|
|
This is preparation for PR #73084
|
|
|
|
* Deduplicate type ascription LHS errors
* Remove duplicated `:` -> `::` suggestion from parse error
* Tweak wording to be more accurate
* Modify `current_type_ascription` to reduce span wrangling
* remove now unnecessary match arm
* Add run-rustfix to appropriate tests
|
|
|
|
|
|
Fix #74233.
|
|
Handle case of incomplete local ty more gracefully
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
|
|
When encountering a local binding with a type that isn't completed, the
parser will reach a `=` token. When this happen, consider the type
"complete" as far as the parser is concerned to avoid further errors
being emitted by parse recovery logic.
|
|
In various ways, such as changing functions to take a `Symbol` instead
of a `&str`.
|
|
Correctly mark the ending span of a match arm
Closes #74050
r? @matthewjasper
|
|
Accept tuple.0.0 as tuple indexing (take 2)
If we expect something identifier-like when parsing a field name after `.`, but encounter a float token, we break that float token into parts, similarly to how we break `&&` into `&` `&`, or `<<` into `<` `<`, etc.
An alternative to https://github.com/rust-lang/rust/pull/70420.
|
