about summary refs log tree commit diff
path: root/src/librustc_parse/parser
AgeCommit message (Collapse)AuthorLines
2020-02-09[parser] change an instance of span_bug() to struct_span_err() to avoid ICEDavid Renshaw-1/+4
2020-02-10Rollup merge of #69006 - petrochenkov:prevspan2, r=CentrilDylan DPC-24/+52
parser: Keep current and previous tokens precisely ...including their unnormalized forms. Add more documentation for them. Hopefully, this will help to eliminate footguns like https://github.com/rust-lang/rust/pull/68728#discussion_r373787486. I'll try to address the FIXMEs in separate PRs during the next week. r? @Centril
2020-02-10parser: Keep current and previous tokens preciselyVadim Petrochenkov-24/+52
including their unnormalized forms. Add more documentation for them.
2020-02-09Make issue references consistentMatthias Prechtl-3/+6
2020-02-09Don't parse `mut a @ b` as `mut a @ mut b`Matthew Jasper-4/+7
2020-02-06Rollup merge of #68845 - dwrensha:fix-68783, r=estebankDylan DPC-17/+22
stop using BytePos for computing spans in librustc_parse/parser/mod.rs Computing spans using logic such as `self.token.span.lo() + BytePos(1)` can cause internal compiler errors like #68730 when non-ascii characters are given as input. #68735 partially addressed this problem, but only for one case. Moreover, its usage of `next_point()` does not actually align with what `bump_with()` expects. For example, given the token `>>=`, we should pass the span consisting of the final two characters `>=`, but `next_point()` advances the span beyond the end of the `=`. This pull request instead computes the start of the new span by doing `start_point(self.token.span).hi()`. This matches `self.token.span.lo() + BytePos(1)` in the common case where the characters are ascii, and it gracefully handles multibyte characters. Fixes #68783.
2020-02-06Remove the `Cow` from `Directory`.Nicholas Nethercote-8/+7
The previous commit wrapped `Parser` within a `Cow` for the hot macro parsing path. As a result, there's no need for the `Cow` within `Directory`, because it lies within `Parser`.
2020-02-04stop using BytePos for computing spans in librustc_parse/parser/mod.rsDavid Renshaw-17/+22
2020-02-05parser: merge `fn` grammars wrt. bodies & headersMazdak Farrokhzad-115/+59
also refactor `FnKind` and `visit_assoc_item` visitors
2020-02-05parse_ty_common: use `enum`s instead of `bool`s.Mazdak Farrokhzad-29/+52
2020-02-04Auto merge of #68377 - estebank:fn-obligations-spans, r=oli-obkbors-1/+1
Tweak obligation error output - Point at arguments or output when fn obligations come from them, or ident when they don't - Point at `Sized` bound (fix #47990) - When object unsafe trait uses itself in associated item suggest using `Self` (fix #66424, fix #33375, partially address #38376, cc #61525) - Point at reason in object unsafe trait with `Self` in supertraits or `where`-clause (cc #40533, cc #68377) - On implicit type parameter `Sized` obligations, suggest `?Sized` (fix #57744, fix #46683)
2020-02-03Auto merge of #68735 - JohnTitor:fix-ice-0202, r=estebankbors-2/+2
Use `next_point` to avoid ICE Fixes #68730 r? @estebank (I think you're familiar with that)
2020-02-02Use more appropriate spans on object unsafe traits and provide structured ↵Esteban Küber-1/+1
suggestions when possible
2020-02-02Rollup merge of #68769 - Centril:unwrap, r=petrochenkovMazdak Farrokhzad-4/+3
parser: avoid re-wrapping NtItem r? @petrochenkov
2020-02-02Rollup merge of #68764 - Centril:self-semantic, r=petrochenkovMazdak Farrokhzad-62/+30
parser: syntactically allow `self` in all `fn` contexts Part of https://github.com/rust-lang/rust/pull/68728. `self` parameters are now *syntactically* allowed as the first parameter irrespective of item context (and in function pointers). Instead, semantic validation (`ast_validation`) is used. r? @petrochenkov
2020-02-02parser: avoid re-wrapping NtItemMazdak Farrokhzad-4/+3
2020-02-02parser: address review comments re. `self`.Mazdak Farrokhzad-39/+15
2020-02-02parser: move restrictions re. `self` to `ast_validation`.Mazdak Farrokhzad-42/+34
2020-02-02Rollup merge of #68681 - bobrippling:fix-matched-angle-brackets, r=CentrilYuki Okushi-1/+36
Suggest path separator for single-colon typos This commit adds guidance for when a user means to type a path, but ends up typing a single colon, such as `<<Impl as T>:Ty>`. This change seemed pertinent as the current error message is particularly misleading, emitting `error: unmatched angle bracket`, despite the angle bracket being matched later on, leaving the user to track down the typo'd colon.
2020-02-01Avoid qualified path recovery when not followed by identifierRob Pilling-1/+5
2020-02-01Improve wording and docs for qualified path recoveryRob Pilling-4/+11
2020-02-01Move colon-check to recover_colon_before_qpath_proj()Rob Pilling-15/+23
2020-02-01Simplify span usage and avoid .eat()Rob Pilling-5/+5
2020-02-01syntax::print -> new crate rustc_ast_prettyMazdak Farrokhzad-6/+6
2020-02-011. move node_id to syntaxMazdak Farrokhzad-1/+1
2. invert rustc_session & syntax deps 3. drop rustc_session dep in rustc_hir
2020-02-02Use `next_point` to avoid ICEYuki Okushi-2/+2
2020-01-31Auto merge of #68633 - JohnTitor:avoid-ice-in-diagnostics, r=estebankbors-17/+23
Avoid ICE in macro's diagnostics Fixes #68629 r? @estebank
2020-01-31Auto merge of #67340 - nnethercote:shrink-Nonterminal, r=petrochenkovbors-18/+18
Shrink `Nonterminal` These commits shrink `Nonterminal` from 240 bytes to 40 bytes. When building `serde_derive` they reduce the number of `memcpy` calls from 9.6M to 7.4M, and it's a tiny win on a few other benchmarks. r? @petrochenkov
2020-01-30Suggest path separator for single-colon typosRob Pilling-1/+17
This commit adds guidance for when a user means to type a path, but ends up typing a single colon, such as `<<Impl as T>:Ty>`. This change seemed pertinent as the current error message is particularly misleading, emitting `error: unmatched angle bracket`, despite the angle bracket being matched later on, leaving the user to track down the typo'd colon.
2020-01-30suggest adding space in accidental doc commentsAndy Russell-2/+19
2020-01-30Change Applicability to `HasPlaceholders`Yuki Okushi-1/+1
2020-01-30Use `P` for `NtMeta`.Nicholas Nethercote-1/+1
This commit reduces the size of `Nonterminal` from a 72 bytes to 40 bytes (on x86-64).
2020-01-30Use `P` for `NtTraitItem`, `NtImplItem`, and `NtForeignItem`.Nicholas Nethercote-17/+17
This commit reduces the size of `Nonterminal` from a whopping 240 bytes to 72 bytes (on x86-64), which gets it below the `memcpy` threshold. It also removes some impedance mismatches with `Annotatable`, which already uses `P` for these variants.
2020-01-29Avoid ICE in macro's diagnosticsYuki Okushi-17/+23
2020-01-21Rollup merge of #68140 - ecstatic-morse:const-trait-bound-opt-out, r=oli-obkMazdak Farrokhzad-20/+16
Implement `?const` opt-out for trait bounds For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](https://github.com/rust-lang/rfcs/pull/2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment. Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR. After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering. cc #67794 r? @oli-obk
2020-01-20Parse `?const ?Trait`Dylan MacKenzie-18/+5
2020-01-20Add `MaybeConst` variant to `{ast,hir}::TraitBoundModifier`Dylan MacKenzie-9/+24
2020-01-19Store `impl const` in `ItemKind::Impl`Dylan MacKenzie-12/+4
2020-01-19Add `constness` field to `ast::ItemKind::Impl`Dylan MacKenzie-0/+2
2020-01-18remove rustc_error_codes deps except in rustc_driverMazdak Farrokhzad-6/+0
2020-01-17Use named fields for `ast::ItemKind::Impl`Dylan MacKenzie-10/+10
2020-01-16Rollup merge of #68096 - varkor:diagnostic-cleanup, r=CentrilDylan DPC-4/+4
Clean up some diagnostics by making them more consistent In general: - Diagnostic should start with a lowercase letter. - Diagnostics should not end with a full stop. - Ellipses contain three dots. - Backticks should encode Rust code. I also reworded a couple of messages to make them read more clearly. It might be sensible to create a style guide for diagnostics, so these informal conventions are written down somewhere, after which we could audit the existing diagnostics. r? @Centril
2020-01-15remove redundant clones, found by clippyMatthias Krüger-1/+1
2020-01-13Rollup merge of #68135 - calebcartwright:rustc-parse-visibilities, r=CentrilYuki Okushi-8/+17
restore some rustc_parse visibilities for rustfmt In https://github.com/rust-lang/rust/pull/65495/commits/c189565edc5c9fc516170885b3a3061b936205fb some visibilities were reduced on the parse mod (which now resides in the rustc_parse crate) as part of some refactoring and splitting up of libsyntax. However, rustfmt needs access to a few of those items that are no longer visible. This restores the visibility on those items rustfmt depends on. https://github.com/rust-lang/rustfmt/issues/3903#issuecomment-563596269 https://github.com/rust-lang/rustfmt/issues/4009 cc @topecongiro
2020-01-12Fix formatting ellipses at the end of some diagnosticsvarkor-2/+2
2020-01-12Add backticks in appropriate placesvarkor-2/+2
2020-01-12Rollup merge of #68108 - varkor:chained-comparison-suggestions, r=CentrilMazdak Farrokhzad-32/+93
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-11restore some rustc_parse visibilitiesCaleb Cartwright-8/+17
2020-01-11Rollup merge of #68120 - Centril:ban-range-to-dotdotdot, r=oli-obkMazdak Farrokhzad-4/+24
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-4/+24
Also fix a bug with the span passed in `mk_range`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-24 02:24:13 +0000