summary refs log tree commit diff
path: root/src/librustc_parse/parser
AgeCommit message (Collapse)AuthorLines
2020-02-15ast: normalize `ForeignItemKind::Ty` & `AssocItemKind::TyAlias`.Mazdak Farrokhzad-5/+7
2020-02-15ast: move Generics into AssocItemKindsMazdak Farrokhzad-8/+8
2020-02-15parser: `macro_rules` is a weak keywordVadim Petrochenkov-2/+2
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-13parser: inline parse_assoc_macro_invocMazdak Farrokhzad-20/+10
2020-02-13parser: misc small item related improvements & cleanups.Mazdak Farrokhzad-150/+131
2020-02-13parser: extract `recover_const_mut`.Mazdak Farrokhzad-13/+17
2020-02-13parser: fuse `trait` parsing & layer with `is_path_start_item`Mazdak Farrokhzad-35/+27
2020-02-13parser: make `eat_macro_def` redundant.Mazdak Farrokhzad-33/+12
2020-02-13parser: remove `Option<Vec<Attribute>>` in `ItemInfo`.Mazdak Farrokhzad-59/+50
2020-02-13parser_item_mod: avoid cloning outer attributesMazdak Farrokhzad-15/+13
2020-02-13parser: introduce `parse_item_kind` as central `ItemInfo` logic.Mazdak Farrokhzad-192/+156
this also extracts macro item parsers.
2020-02-13parser: extract `recover_missing_kw_before_item`Mazdak Farrokhzad-84/+90
2020-02-13parser: unify item list parsing.Mazdak Farrokhzad-56/+46
as a consequence, `trait X { #![attr] }` becomes legal.
2020-02-13parser: extract common foreign item code for each kindMazdak Farrokhzad-67/+21
2020-02-13macro_legacy_warnings -> errorMazdak Farrokhzad-53/+9
2020-02-13parser: is_fn_front_matter -> check_fn_front_matterMazdak Farrokhzad-4/+4
2020-02-13parser: simplify ParamCfg -> ReqNameMazdak Farrokhzad-30/+18
2020-02-13parser: address review commentsMazdak Farrokhzad-1/+1
2020-02-13parser: move `ban_async_in_2015` to `fn` parsing & improve it.Mazdak Farrokhzad-13/+12
2020-02-13parser: inline `parse_assoc_fn` and friends.Mazdak Farrokhzad-42/+21
2020-02-13parser: solidify `fn` parsing with `parse_fn`.Mazdak Farrokhzad-23/+30
2020-02-13parser: fuse free `fn` parsing together.Mazdak Farrokhzad-86/+25
2020-02-13parser_fn_front_matter: allow `const .. extern`Mazdak Farrokhzad-54/+53
2020-02-13IsAsync -> enum Async { Yes { span: Span, .. }, No }Mazdak Farrokhzad-41/+16
use new span for better diagnostics.
2020-02-13Constness -> enum Const { Yes(Span), No }Mazdak Farrokhzad-46/+43
Same idea for `Unsafety` & use new span for better diagnostics.
2020-02-13Rollup merge of #68848 - nnethercote:hasten-macro-parsing, r=petrochenkovDylan DPC-8/+7
Hasten macro parsing r? @eddyb
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-56/+25
parser: Remove `Parser::prev_token_kind` Follow-up to https://github.com/rust-lang/rust/pull/69006. r? @Centril
2020-02-11Run RustFmtjumbatm-1/+3
2020-02-11Invert control in struct_lint_level.jumbatm-5/+5
Caller now passes in a `decorate` function, which is only run if the lint is allowed.
2020-02-11Auto merge of #68929 - matprec:consistent-issue-references, r=Dylan-DPCbors-3/+6
Make issue references consistent Fixes https://github.com/rust-lang/rust/issues/62976 cc https://github.com/rust-lang/rust/pull/63008 r? @varkor because you reviewed the original pr
2020-02-10review comment: wordingEsteban Küber-1/+1
2020-02-10parser: Remove `Parser::prev_token_kind`Vadim Petrochenkov-56/+25
2020-02-10Rollup merge of #69014 - dwrensha:fix-68890, r=CentrilDylan DPC-1/+4
change an instance of span_bug() to struct_span_err() to avoid ICE After #67148, the `span_bug()` in `parse_ty_tuple_or_parens()` is reachable because `parse_paren_comma_seq()` can return an `Ok()` even in cases where it encounters an error. This pull request prevents an ICE in such cases by replacing the `span_bug()` with `struct_span_error()`. Fixes #68890.
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