| Age | Commit message (Collapse) | Author | Lines |
|
Do not emit type errors after parse error in last statement of block
When recovering from a parse error inside a block, do not emit type
errors generating on that block's recovered return expression.
Fix #57383.
|
|
Use snippet instead of pprinting statement
Fix #62554.
|
|
|
|
|
|
If the explicitly given type of a `self` parameter fails to parse correctly,
we need to propagate the error rather than dropping it and causing an ICE.
Fixes #62660.
|
|
|
|
Handle errors during error recovery gracefully
Fix #62546.
|
|
When recovering from a parse error inside a block, do not emit type
errors generating on that block's recovered return expression.
Fix #57383.
|
|
|
|
Correctly break out of recovery loop
Fix #61858.
|
|
|
|
|
|
|
|
We're always indenting by INDENT_UNIT anyway
|
|
|
|
|
|
attribute_to_string exists.
|
|
|
|
They always end up interned anyway
|
|
Remove support for 1-token lookahead from the lexer
`StringReader` maintained `peek_token` and `peek_span_src_raw` for look ahead.
`peek_token` was used only by rustdoc syntax coloring. After moving peeking logic into highlighter, I was able to remove `peek_token` from the lexer. I tried to use `iter::Peekable`, but that wasn't as pretty as I hoped, due to buffered fatal errors. So I went with hand-rolled peeking.
After that I've noticed that the only peeking behavior left was for raw tokens to test tt jointness. I've rewritten it in terms of trivia tokens, and not just spans.
After that it became possible to simplify the awkward constructor of the lexer, which could return `Err` if the first peeked token contained error.
|
|
Move `async || ...` closures into `#![feature(async_closure)]`
The `async || expr` syntax is moved out from `#![feature(async_await)]` into its own gate `#![feature(async_closure)]`.
New tracking issue: https://github.com/rust-lang/rust/issues/62290
Closes https://github.com/rust-lang/rust/issues/62214.
cc https://github.com/rust-lang/rust/issues/62149
r? @varkor
|
|
Remove io::Result from syntax::print
Since we're now writing directly to the vector, there's no need to
thread results through the whole printing infrastructure
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The reader itself doesn't need ability to peek tokens, so it's better
if clients implement this functionality.
This hopefully becomes especially easy once we use iterator interface
for lexer, but this is not too easy at the moment, because of buffered
errors.
|
|
refactor check_for_substitution
No behavior change, just flatter and simpler code.
r? @petrochenkov
|
|
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in https://github.com/rust-lang/rust/pull/61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc https://github.com/rust-lang-nursery/wg-grammar/issues/51
|
|
|
|
No behavior change, just flatter and simpler code
|
|
|
|
|
|
Unreserve `macro_rules` as a macro name
|
|
|
|
Since we're now writing directly to the vector, there's no need to
thread results through the whole printing infrastructure
|
|
Remove old fixme
fixed in https://github.com/rust-lang/rust/pull/60160
r? @Centril
|
|
libsyntax: Fix some Clippy warnings
When I was working on it before a lot of these popped up in the RLS so I figured I'll send a small patch fixing only the (hopefully) uncontroversial ones.
Others that could be also fixed included also [`clippy::print_with_newline`](https://rust-lang.github.io/rust-clippy/master/index.html#print_with_newline) and [`clippy::cast_lossless`](https://rust-lang.github.io/rust-clippy/master/index.html#cast_lossless). Should I add them as well?
since most of it touches libsyntax...
r? @petrochenkov
|
|
refactor lexer to use idiomatic borrowing
|
|
|
|
|
|
Lexer uses Symbols for a lot of stuff, not only for identifiers, so
the "name" terminology is just confusing.
|
|
|
|
Implement arbitrary_enum_discriminant
Implements RFC rust-lang/rfcs#2363 (tracking issue #60553).
|
|
Remove `ast::Guard`
With the introduction of `ast::ExprKind::Let` in https://github.com/rust-lang/rust/pull/60861, the `ast::Guard` structure is now redundant in terms of representing [`if let` guards](https://github.com/rust-lang/rust/issues/51114) in AST since it can be represented by `ExprKind::Let` syntactically. Therefore, we remove `ast::Guard` here.
However, we keep `hir::Guard` because the semantic representation is a different matter and this story is more unclear right now (might involve `goto 'arm` in HIR or something...).
r? @petrochenkov
|
|
|