about summary refs log tree commit diff
path: root/src/libsyntax/parse
AgeCommit message (Collapse)AuthorLines
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-18Rollup merge of #65455 - ↵Tyler Mandry-11/+10
nnethercote:avoid-unnecessary-TokenTree-to-TokenStream-conversions, r=petrochenkov Avoid unnecessary `TokenTree` to `TokenStream` conversions A `TokenStream` contains any number of `TokenTrees`. Therefore, a single `TokenTree` can be promoted to a `TokenStream`. But doing so costs two allocations: one for the single-element `Vec`, and one for the `Lrc`. (An `IsJoint` value also must be added; the default is `NonJoint`.) The current code converts `TokenTree`s to `TokenStream`s unnecessarily in a few places. This PR removes some of these unnecessary conversions, both simplifying the code and speeding it up. r? @petrochenkov
2019-10-18Rollup merge of #65364 - XiangQingW:master, r=estebankTyler Mandry-3/+20
Collect occurrences of empty blocks for mismatched braces diagnostic Fix #63904
2019-10-18Clarify diagnostics when using `~` as a unary opYuki Okushi-1/+1
2019-10-18Change `Lit::tokens()` to `Lit::token_tree()`.Nicholas Nethercote-9/+8
Because most of the call sites have an easier time working with a `TokenTree` instead of a `TokenStream`.
2019-10-18Remove two no-op `into()` calls.Nicholas Nethercote-2/+2
2019-10-16ui-fulldeps: make them pass again?Mazdak Farrokhzad-3/+3
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-30/+31
2019-10-16move syntax::ext to new crate syntax_expandMazdak Farrokhzad-30/+30
2019-10-16syntax::parse: don't depend on syntax::extMazdak Farrokhzad-6/+12
2019-10-16syntax: reduce visibilitiesMazdak Farrokhzad-97/+97
2019-10-16move diagnostics.rs into parser/Mazdak Farrokhzad-6/+7
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-1/+1
2019-10-15Collect occurrences of for mismatched braces diagnosticwangxiangqing-1/+1
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
2019-10-15Rollup merge of #65426 - ↵Mazdak Farrokhzad-1/+1
nnethercote:rm-custom-LocalInternedString-PartialEq-impls, r=petrochenkov Remove custom `PartialEq` impls for `LocalInternedString`. This is on-trend with the recent changes simplifying `LocalInternedString` and reducing its use. r? @petrochenkov
2019-10-15syntax::parse::sess -> syntax::sessMazdak Farrokhzad-128/+4
2019-10-15move parse_lit to expr.rsMazdak Farrokhzad-177/+170
2019-10-15syntax: extract sess.rs for ParseSessMazdak Farrokhzad-119/+132
2019-10-15move maybe_report_invalid_custom_discriminants to feature_gateMazdak Farrokhzad-52/+3
2019-10-15Remove custom `PartialEq` impls for `LocalInternedString`.Nicholas Nethercote-1/+1
This is on-trend with the recent changes simplifying `LocalInternedString` and reducing its use.
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-14Rollup merge of #65261 - nnethercote:rm-Option-from-TokenStream, r=petrochenkovTyler Mandry-3/+3
Remove `Option` from `TokenStream` A code simplification. r? @petrochenkov
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 #65392 - Centril:nt-to-tt, r=Mark-SimulacrumMazdak Farrokhzad-138/+137
Move `Nonterminal::to_tokenstream` to parser & don't rely directly on parser in lowering Split out from https://github.com/rust-lang/rust/pull/65324. r? @petrochenkov
2019-10-14Rollup merge of #65363 - Centril:less-pprust, r=Mark-SimulacrumMazdak Farrokhzad-5/+10
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-14Rollup merge of #65362 - Centril:extract_fun, r=petrochenkovMazdak Farrokhzad-487/+491
syntax: consolidate function parsing in item.rs Extracted from https://github.com/rust-lang/rust/pull/65324. r? @estebank
2019-10-14Use `TokenStream::default()` in more places.Nicholas Nethercote-2/+2
2019-10-14Remove the `Option` in `TokenStream`.Nicholas Nethercote-1/+1
It means an allocation is required to create an empty `TokenStream`, but all other operations are simpler and marginally faster due to not having to check for `None`. Overall it simplifies the code for a negligible performance effect. The commit also removes `TokenStream::empty` by implementing `Default`, which is now possible.
2019-10-13token: extract Nonterminal::to_tokenstream to parser.Mazdak Farrokhzad-138/+137
2019-10-13syntax: consolidate function parsing in `item.rs`Mazdak Farrokhzad-487/+491
2019-10-13Rollup merge of #65359 - Centril:sil, r=davidtwcoMazdak Farrokhzad-9/+6
simplify integer_lit Extracted from https://github.com/rust-lang/rust/pull/65324. r? @davidtwco
2019-10-13Collect occurrences of for mismatched braces diagnosticwangxiangqing-1/+4
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
2019-10-13Collect occurrences of for mismatched braces diagnosticwangxiangqing-3/+17
Change-Id: I20ba0b62308370ee961141fa1aefc4b9c9f0cb3a
2019-10-13ast: remove implicit pprust dependency via Display.Mazdak Farrokhzad-5/+10
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-13simplify integer_litMazdak Farrokhzad-9/+6
2019-10-13syntax: simplify maybe_annotate_with_ascriptionMazdak Farrokhzad-9/+11
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-91/+74
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/+45
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.