about summary refs log tree commit diff
path: root/src/librustc_parse/parser/expr.rs
AgeCommit message (Collapse)AuthorLines
2020-03-09Address review commentsVadim Petrochenkov-7/+6
2020-03-09Use `Token::uninterpolate` in couple more places matching on `(Nt)Ident`Vadim Petrochenkov-2/+1
2020-03-09rustc_ast: Introduce `Token::uninterpolate`Vadim Petrochenkov-2/+2
2020-03-09rustc_ast: Introduce `Token::uninterpolated_span`Vadim Petrochenkov-7/+10
2020-03-09rustc_parse: Use `Token::ident` where possibleVadim Petrochenkov-24/+26
2020-03-07Rollup merge of #69773 - matthiaskrgr:typos, r=petrochenkovMazdak Farrokhzad-1/+1
fix various typos
2020-03-07Rollup merge of #69656 - matthiaskrgr:iter_nth_zero, r=oli-obkMazdak Farrokhzad-1/+1
Use .next() instead of .nth(0) on iterators.
2020-03-07Rollup merge of #68985 - daboross:fix-35813, r=CentrilMazdak Farrokhzad-5/+58
Parse & reject postfix operators after casts This adds an explicit error messages for when parsing `x as Type[0]` or similar expressions. Our add an extra parse case for parsing any postfix operator (dot, indexing, method calls, await) that triggers directly after parsing `as` expressions. My friend and I worked on this together, but they're still deciding on a github username and thus I'm submitting this for both of us. It will immediately error out, but will also provide the rest of the parser with a useful parse tree to deal with. There's one decision we made in how this produces the parse tree. In the situation `&x as T[0]`, one could imagine this parsing as either `&((x as T)[0])` or `((&x) as T)[0]`. We chose the latter for ease of implementation, and as it seemed the most intuitive. Feedback welcome! This is our first change to the parser section, and it might be completely horrible. Fixes #35813.
2020-03-06fix various typosMatthias Krüger-1/+1
2020-03-04Permit attributes on 'if' expressionsAaron Hill-9/+0
Previously, attributes on 'if' expressions (e.g. #[attr] if true {}) were disallowed during parsing. This made it impossible for macros to perform any custom handling of such attributes (e.g. stripping them away), since a compilation error would be emitted before they ever had a chance to run. This PR permits attributes on 'if' expressions ('if-attrs' from here on). Both built-in attributes (e.g. `#[allow]`, `#[cfg]`) are supported. We still do *not* accept attributes on 'other parts' of an if-else chain. That is, the following code snippet still fails to parse: ```rust if true {} #[attr] else if false {} else #[attr] if false {} #[attr] else {} ```
2020-03-03Use .next() instead of .nth(0) on iterators.Matthias Krüger-1/+1
2020-03-01Rollup merge of #69579 - petrochenkov:noprevspan, r=CentrilYuki Okushi-60/+69
parser: Remove `Parser::prev_span` Follow-up to https://github.com/rust-lang/rust/pull/69384. r? @Centril
2020-02-29Replace ptr hashing with ptr castingDavid-15/+6
Implementes suggeseted changes by Centril. This checks whether the memory location of the cast remains the same after atttempting to parse a postfix operator after a cast has been parsed. If the address is not the same, an illegal postfix operator was parsed. Previously the code generated a hash of the pointer, which was overly complex and inefficent. Casting the pointers and comparing them is simpler and more effcient.
2020-02-29Rename `syntax` to `rustc_ast` in source codeVadim Petrochenkov-8/+8
2020-02-29parser: Remove `Parser::prev_span`Vadim Petrochenkov-1/+1
2020-02-29parser: `prev_span` -> `prev_token.span`Vadim Petrochenkov-59/+68
2020-02-28Rollup merge of #69481 - matthiaskrgr:single_char, r=ecstatic-morseMazdak Farrokhzad-1/+1
use char instead of &str for single char patterns
2020-02-28Rollup merge of #69384 - petrochenkov:nounnorm, r=CentrilMazdak Farrokhzad-21/+18
parser: `token` -> `normalized_token`, `nonnormalized_token` -> `token` So, after https://github.com/rust-lang/rust/pull/69006, its follow-ups and an attempt to remove `Parser::prev_span` I came to the conclusion that the unnormalized token and its span is what you want in most cases, so it should be default. Normalization only makes difference in few cases where we are checking against `token::Ident` or `token::Lifetime` specifically. This PR uses `normalized_token` for those cases. Using normalization explicitly means that people writing code should remember about `NtIdent` and `NtLifetime` in general. (That is alleviated by the fact that `token.ident()` and `fn parse_ident_*` are already written.) Remembering about `NtIdent`, was, however, already the case, kind of, because the implicit normalization was performed only for the current/previous token, but not for things like `look_ahead`. As a result, most of token classification methods in `token.rs` already take `NtIdent` into account (this PR fixes a few pre-existing minor mistakes though). The next step is removing `normalized(_prev)_token` entirely and replacing it with `token.ident()` (mostly) and `token.normalize()` (occasionally). I want to make it a separate PR for that and run it though perf. `normalized_token` filled on every bump has both a potential to avoid repeated normalization, and to do unnecessary work in advance (it probably doesn't matter anyway, the normalization is very cheap). r? @Centril
2020-02-27use char instead of &str for single char patternsMatthias Krüger-1/+1
2020-02-27use find(x) instead of filter(x).next()Matthias Krüger-6/+2
2020-02-24parser: `token` -> `normalized_token`, `nonnormalized_token` -> `token`Vadim Petrochenkov-21/+18
2020-02-22Use multipart suggestionDavid Ross-13/+9
This is a modified version of estebank's suggestion, with a bit of extra cleanup now that we don't need the different cases for if we can turn a span into a string or not.
2020-02-22Rename CodeMap to SourceMap follow upMaxim Zholobak-2/+2
2020-02-17parser: Remove `Option`s from unnormalized tokensVadim Petrochenkov-2/+2
They are always set synchronously with normalized tokens now
2020-02-17Rename `FunctionRetTy` to `FnRetTy`Yuki Okushi-4/+2
2020-02-15Remove extra debug print in unreachable!David Ross-2/+1
2020-02-15Keep better fix suggestion if type ascription is likely unintendedDavid Ross-9/+15
2020-02-15Type ascription outputs a Type, not CastDavid Ross-1/+3
Previously this just errored out on all usages of type ascription, which isn't helpful.
2020-02-15Refactor out error case & apply suggestions.David Ross-20/+42
This is almost entirely refactoring and message changing, with the single behavioral change of panicking for unexpected output.
2020-02-15Parse & reject postfix operators after castsDavid Ross-2/+39
This adds parsing for expressions like 'x as Ty[0]' which will immediately error out, but still give the rest of the parser a valid parse tree to continue.
2020-02-14Suggest a comma if a struct initializer field fails to parseAaron Hill-1/+7
Currently, we emit a "try adding a comma" suggestion if a comma is missing in a struct definition. However, we emit no such suggestion if a comma is missing in a struct initializer. This commit adds a "try adding a comma" suggestion when we don't find a comma during the parsing of a struct initializer field. The change to `src/test/ui/parser/removed-syntax-with-1.stderr` isn't great, but I don't see a good way of avoiding it.
2020-02-13IsAsync -> enum Async { Yes { span: Span, .. }, No }Mazdak Farrokhzad-2/+2
use new span for better diagnostics.
2020-02-12Rollup merge of #68981 - estebank:silence, r=davidtwcoDylan DPC-1/+1
Account for type params on method without parentheses Account for those type parameters in the structured suggestion when forgetting to call method: ``` error[E0615]: attempted to take value of method `collect` on type `std::vec::IntoIter<_>` --> $DIR/method-missing-parentheses.rs:2:32 | LL | let _ = vec![].into_iter().collect::<usize>; | ^^^^^^^--------- | | | help: use parentheses to call the method: `collect::<usize>()` ```
2020-02-12Rollup merge of #69034 - petrochenkov:notokind, r=CentrilDylan DPC-17/+12
parser: Remove `Parser::prev_token_kind` Follow-up to https://github.com/rust-lang/rust/pull/69006. r? @Centril
2020-02-10review comment: wordingEsteban Küber-1/+1
2020-02-10parser: Remove `Parser::prev_token_kind`Vadim Petrochenkov-17/+12
2020-02-09Make issue references consistentMatthias Prechtl-1/+4
2020-02-05parse_ty_common: use `enum`s instead of `bool`s.Mazdak Farrokhzad-1/+2
2020-02-01syntax::print -> new crate rustc_ast_prettyMazdak Farrokhzad-1/+1
2020-01-12Rollup merge of #68108 - varkor:chained-comparison-suggestions, r=CentrilMazdak Farrokhzad-19/+23
Add suggestions when encountering chained comparisons Ideally, we'd also prevent the type error, which is just extra noise, but that will require moving the error from the parser, and I think the suggestion makes things clear enough for now. Fixes https://github.com/rust-lang/rust/issues/65659.
2020-01-11Rollup merge of #68120 - Centril:ban-range-to-dotdotdot, r=oli-obkMazdak Farrokhzad-1/+1
Ban `...X` pats, harden tests, and improve diagnostics Follow up to https://github.com/rust-lang/rust/pull/67258#issuecomment-565656155 and https://github.com/rust-lang/rust/pull/67258#discussion_r357879932. r? @cramertj @oli-obk
2020-01-11Ban `...X` pats, harden tests, and improve diagnostics.Mazdak Farrokhzad-1/+1
Also fix a bug with the span passed in `mk_range`.
2020-01-11Rollup merge of #68084 - estebank:ice-68000, r=varkorMazdak Farrokhzad-1/+1
Do not ICE on unicode next point Use `shrink_to_hi` instead of `next_point` and fix `next_point`. Fix #68000, fix #68091, fix #68092.
2020-01-11Add suggestions when encountering chained comparisonsvarkor-19/+23
2020-01-10Change `next_point` when `shrink_to_hi` is more appropriateEsteban Küber-1/+1
2020-01-10Introduce `#![feature(half_open_range_patterns)]`.Mazdak Farrokhzad-2/+2
This feature adds `X..`, `..X`, and `..=X` patterns.
2020-01-01Rename `syntax_pos` to `rustc_span` in source codeVadim Petrochenkov-2/+2
2019-12-31parser: bug -> span_bugMazdak Farrokhzad-1/+1
2019-12-31parser::path: remove .fatal callsMazdak Farrokhzad-3/+1
2019-12-31parser: span_fatal -> struct_span_errMazdak Farrokhzad-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2025-11-07 17:13:50 +0000