about summary refs log tree commit diff
path: root/src/libsyntax/parse/parser
AgeCommit message (Collapse)AuthorLines
2019-10-24pre-expansion gate associated_type_boundsMazdak Farrokhzad-2/+10
2019-10-24pre-expansion gate trait_alias.Mazdak Farrokhzad-0/+2
2019-10-24syntax: reject `trait Foo: Bar = Baz;`.Mazdak Farrokhzad-8/+20
Add test for rejecting `trait A: B1 = B2;`. Also test rejection of `trait A: = B;`.
2019-10-23Rollup merge of #65686 - yjhmelody:yjhmelody-patch-1, r=CentrilYuki Okushi-2/+8
refactor and move `maybe_append`
2019-10-22refactor maybe_appendyjhmelody-2/+8
2019-10-18Rollup merge of #65552 - JohnTitor:use-bitwise-not, r=Dylan-DPCTyler Mandry-1/+1
Clarify diagnostics when using `~` as a unary op It seems we prefer `bitwise not` to `bitwise negation`. Fixes #57239 r? @estebank
2019-10-18Clarify diagnostics when using `~` as a unary opYuki Okushi-1/+1
2019-10-18Change `Lit::tokens()` to `Lit::token_tree()`.Nicholas Nethercote-5/+4
Because most of the call sites have an easier time working with a `TokenTree` instead of a `TokenStream`.
2019-10-16ui-fulldeps: make them pass again?Mazdak Farrokhzad-2/+2
2019-10-16make tidy happyMazdak Farrokhzad-3/+13
2019-10-16parser: leave a FIXME for laterMazdak Farrokhzad-0/+2
2019-10-16move SeqSep to parser.rsMazdak Farrokhzad-4/+5
2019-10-16move syntax::ext to new crate syntax_expandMazdak Farrokhzad-15/+15
2019-10-16syntax::parse: don't depend on syntax::extMazdak Farrokhzad-6/+12
2019-10-16syntax: reduce visibilitiesMazdak Farrokhzad-65/+67
2019-10-16move diagnostics.rs into parser/Mazdak Farrokhzad-4/+1488
2019-10-16syntax: extract parse_cfg_attrMazdak Farrokhzad-0/+21
2019-10-16syntax: extract parse_derive_pathsMazdak Farrokhzad-1/+16
2019-10-16move parse::attr -> parse::parser::attrMazdak Farrokhzad-0/+330
2019-10-15move parse_lit to expr.rsMazdak Farrokhzad-6/+166
2019-10-14Rollup merge of #65410 - Centril:intersection-pat-recover, r=davidtwco,varkorTyler Mandry-0/+60
syntax: add parser recovery for intersection- / and-patterns `p1 @ p2` Fixes https://github.com/rust-lang/rust/issues/65400. The recovery comes in two flavors: 1. We know that `p2` is a binding so we can invert as `p2 @ p1`: ```rust error: pattern on wrong side of `@` --> $DIR/intersection-patterns.rs:13:9 | LL | Some(x) @ y => {} | -------^^^- | | | | | binding on the right, should be to the left | pattern on the left, should be to the right | help: switch the order: `y @ Some(x)` ``` 2. Otherwise we emit a generic diagnostic for the lack of support for intersection patterns: ```rust error: left-hand side of `@` must be a binding --> $DIR/intersection-patterns.rs:23:9 | LL | Some(x) @ Some(y) => {} | -------^^^------- | | | | | also a pattern | interpreted as a pattern, not a binding | = note: bindings are `x`, `mut x`, `ref x`, and `ref mut x` ``` For more on and-patterns, see e.g. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/pattern-matching#and-pattern. r? @davidtwco cc @varkor @lzutao
2019-10-14recover_intersection_pat: adjust wordingMazdak Farrokhzad-3/+3
2019-10-14syntax: use `PatKind::Wild` as our `::Err` equivalent.Mazdak Farrokhzad-10/+10
2019-10-14syntax: add recovery for intersection patterns `p1 @ p2`Mazdak Farrokhzad-0/+60
2019-10-14Rollup merge of #65363 - Centril:less-pprust, r=Mark-SimulacrumMazdak Farrokhzad-2/+5
Remove implicit dependencies on syntax::pprust Part of https://github.com/rust-lang/rust/pull/65324. The main goal here is to facilitate the eventual move of pprust out from libsyntax and because an AST definition typically should not depend on its pretty printer. r? @estebank
2019-10-13syntax: consolidate function parsing in `item.rs`Mazdak Farrokhzad-206/+487
2019-10-13ast: remove implicit pprust dependency via Display.Mazdak Farrokhzad-2/+5
Instead just use `pprust::path_to_string(..)` where needed. This has two benefits: a) The AST definition is now independent of printing it. (Therefore we get closer to extracting a data-crate.) b) Debugging should be easier as program flow is clearer.
2019-10-07syntax: refactor with new `fn parse_use_tree_glob_or_nested`.Mazdak Farrokhzad-10/+11
2019-10-07syntax: use `parse_extern_abi` more.Mazdak Farrokhzad-8/+1
2019-10-07syntax: unify and simplify fn signature parsing.Mazdak Farrokhzad-33/+36
2019-10-07syntax: unify trait parsing a bit.Mazdak Farrokhzad-17/+12
2019-10-07syntax: further item parsing cleanupMazdak Farrokhzad-24/+35
2019-10-07syntax: de-dups in item parsing.Mazdak Farrokhzad-50/+44
2019-10-07syntax: cleanup associated const parsing.Mazdak Farrokhzad-32/+39
2019-10-07Auto merge of #64906 - Aaron1011:feature/extern-const-fn, r=Centrilbors-19/+34
Add support for `const unsafe? extern fn` This works just as you might expect - an `const extern fn` is a `const fn` that is callable from foreign code. Currently, panicking is not allowed in `const`s. When https://github.com/rust-lang/rfcs/pull/2345 (https://github.com/rust-lang/rust/issues/51999) is stabilized, then panicking in an `const extern fn` will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well. Tracking issue: https://github.com/rust-lang/rust/issues/64926.
2019-10-05Rollup merge of #65123 - Centril:mac-invoc-in-mut-pat, r=estebankTyler Mandry-1/+5
Account for macro invocation in `let mut $pat` diagnostic. Fixes https://github.com/rust-lang/rust/issues/65122. r? @estebank
2019-10-05Account for macro invocation in `let mut $pat` diagnostic.Mazdak Farrokhzad-1/+5
2019-10-03When encountering chained operators use heuristics to recover from bad turbofishEsteban Küber-1/+3
2019-10-02Add missing 'bump'Aaron Hill-0/+1
2019-10-02Add support for 'extern const fn'Aaron Hill-19/+33
This works just as you might expect - an 'extern const fn' is a 'const fn' that is callable from foreign code. Currently, panicking is not allowed in consts. When RFC 2345 is stabilized, then panicking in an 'extern const fn' will produce a compile-time error when invoked at compile time, and an abort when invoked at runtime. Since this is extending the language (we're allowing the `const` keyword in a new context), I believe that this will need an FCP. However, it's a very minor change, so I didn't think that filing an RFC was necessary. This will allow libc (and other FFI crates) to make many functions `const`, without having to give up on making them `extern` as well.
2019-10-01Rollup merge of #64910 - Centril:params-cleanup, r=petrochenkovMazdak Farrokhzad-237/+164
syntax: cleanup param, method, and misc parsing Do some misc cleanup of the parser: - Method and parameter parsing is refactored. - A parser for `const | mut` is introduced that https://github.com/rust-lang/rust/pull/64588 can reuse. - Some other misc parsing. Next up in a different PR: - ~Implementing https://github.com/rust-lang/rust/issues/64252.~ -- maybe some other time... - Heavily restructuring up `item.rs` which is a mess (hopefully, no promises ^^). r? @petrochenkov
2019-10-01Rollup merge of #64887 - Centril:recover-trailing-vert, r=estebankMazdak Farrokhzad-26/+79
syntax: recover trailing `|` in or-patterns Fixes https://github.com/rust-lang/rust/issues/64879. For example (this also shows that we are sensitive to the typo `||`): ``` error: a trailing `|` is not allowed in an or-pattern --> $DIR/remove-leading-vert.rs:33:11 | LL | A || => {} | - ^^ help: remove the `||` | | | while parsing this or-pattern starting here | = note: alternatives in or-patterns are separated with `|`, not `||` ``` r? @estebank
2019-10-01syntax: reformat passing of `FnHeader` to `parse_item_fn`.Mazdak Farrokhzad-12/+16
2019-09-30syntax: Support modern attribute syntax in the `meta` matcherVadim Petrochenkov-3/+3
2019-09-30syntax: reduce repetition in fn parsing.Mazdak Farrokhzad-26/+21
2019-09-30syntax: stylistic cleanup in item parsing.Mazdak Farrokhzad-107/+47
2019-09-30syntax: fuse more code paths together.Mazdak Farrokhzad-48/+51
2019-09-30syntax: cleanup `parse_fn_decl`.Mazdak Farrokhzad-6/+3
2019-09-30syntax refactor `parse_self_param` (4)Mazdak Farrokhzad-6/+2
2019-09-30syntax: cleanup method parsing.Mazdak Farrokhzad-73/+65