about summary refs log tree commit diff
path: root/src/libsyntax
AgeCommit message (Collapse)AuthorLines
2019-08-30Auto merge of #63402 - estebank:strip-margin, r=oli-obkbors-31/+62
Strip code to the left and right in diagnostics for long lines Fix #62999.
2019-08-30Add a "diagnostic item" schemeOliver Scherer-0/+11
This allows lints and other diagnostics to refer to items by a unique ID instead of relying on whacky path resolution schemes that may break when items are relocated.
2019-08-29Rollup merge of #63867 - petrochenkov:dhelpers, r=matthewjasperMazdak Farrokhzad-54/+86
resolve: Block expansion of a derive container until all its derives are resolved So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248). The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468). So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved. After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives. Unblocks https://github.com/rust-lang/rust/pull/63468 r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248) cc @c410-f3r
2019-08-29Rollup merge of #63945 - Centril:recover-mut-pat, r=estebankMazdak Farrokhzad-55/+149
Recover `mut $pat` and other improvements - Recover on e.g. `mut Foo(x, y)` and suggest `Foo(mut x, mut y)`. Fixes https://github.com/rust-lang/rust/issues/63764. - Recover on e.g. `let mut mut x;` - Recover on e.g. `let keyword` and `let keyword(...)`. - Cleanups in `token.rs` with `fn is_non_raw_ident_where` and friends.
2019-08-29Rollup merge of #63938 - tshepang:typo, r=CentrilMazdak Farrokhzad-1/+1
or-pattern: fix typo in error message cc https://github.com/rust-lang/rust/issues/54883.
2019-08-28Auto merge of #63127 - kper:pr, r=nikomatsakisbors-118/+120
Cleanup: Consistently use `Param` instead of `Arg` #62426 Fixes #62426
2019-08-28or-pattern: fix typo in error messageTshepang Lekhonkhobe-1/+1
2019-08-27Improve 'mut ' diagnostic.Mazdak Farrokhzad-20/+34
2019-08-27Ensure 'let mut ;' where ':pat' is banned.Mazdak Farrokhzad-0/+9
2019-08-27Cleanup: Consistently use `Param` instead of `Arg` #62426Kevin Per-118/+120
2019-08-27recover on 'mut ' and improve recovery for keywords.Mazdak Farrokhzad-31/+105
2019-08-27Simplify with Symbol/Token::is_book_lit.Mazdak Farrokhzad-7/+10
2019-08-27token: refactor with is_non_raw_ident_where.Mazdak Farrokhzad-19/+13
2019-08-27Rollup merge of #63761 - petrochenkov:procattrs, r=eddybMazdak Farrokhzad-67/+86
Propagate spans and attributes from proc macro definitions Thanks to https://github.com/rust-lang/rust/pull/63269 we now have spans and attributes from proc macro definitions available in metadata. However, that PR didn't actually put them into use! This PR finishes that work. Attributes `rustc_macro_transparency`, `allow_internal_unstable`, `allow_internal_unsafe`, `local_inner_macros`, `rustc_builtin_macro`, `stable`, `unstable`, `rustc_deprecated`, `deprecated` now have effect when applied to proc macro definition functions. From those attributes only `deprecated` is both stable and supposed to be used in new code. (`#![staged_api]` still cannot be used in proc macro crates for unrelated reasons though.) `Span::def_site` from the proc macro API now returns the correct location of the proc macro definition. Also, I made a mistake in https://github.com/rust-lang/rust/pull/63269#discussion_r312702919, loaded proc macros didn't actually use the resolver cache. This PR fixes the caching issue, now proc macros go through the `Resolver::macro_map` cache as well. (Also, the first commit turns `proc_macro::quote` into a regular built-in macro to reduce the number of places where `SyntaxExtension`s need to be manually created.)
2019-08-27proc_macro: Update `Span::def_site` to use the proc macro definition locationVadim Petrochenkov-8/+8
Which is no longer dummy and is available from metadata now.
2019-08-27Respect attributes on proc macro definitionsVadim Petrochenkov-59/+78
2019-08-26Rollup merge of #63855 - killercup:refactor/feature-gates, r=CentrilMazdak Farrokhzad-302/+404
Refactor feature gates After #63824, this goes a few steps further by - parsing doc comments in the macros to extract descriptions for feature gates, and - introducing a common `Feature` type to replace the tuples used previously to improve readability. The descriptions are not yet used, but I felt like this PR is a useful enough refactoring on its own. r? @Centril
2019-08-26Rollup merge of #63693 - Centril:polish-parse-or-pats, r=estebankMazdak Farrokhzad-109/+210
Fully implement or-pattern parsing Builds upon the initial parsing in https://github.com/rust-lang/rust/pull/61708 to fully implement or-pattern (`p | q`) parsing as specified in [the grammar section of RFC 2535](https://github.com/rust-lang/rfcs/blob/master/text/2535-or-patterns.md#grammar). Noteworthy: - We allow or-patterns in `[p | q, ...]`. - We allow or-patterns in `let` statements and `for` expressions including with leading `|`. - We improve recovery for `p || q` (+ tests for that in `multiple-pattern-typo.rs`). - We improve recovery for `| p | q` in inner patterns (tests in `or-patterns-syntactic-fail.rs`). - We rigorously test or-pattern parsing (in `or-patterns-syntactic-{pass,fail}.rs`). - We harden the feature gating tests. - We do **_not_** change `ast.rs`. That is, `ExprKind::Let.0` and `Arm.pats` still accept `Vec<P<Pat>>`. I was starting work on that but it would be cleaner to do this in a separate PR so this one has a narrower scope. cc @dlrobertson cc the tracking issue https://github.com/rust-lang/rust/issues/54883. r? @estebank
2019-08-27resolve: Block expansion of a derive container until all its derives are ↵Vadim Petrochenkov-54/+86
resolved Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
2019-08-26parser: fix span for leading vert.Mazdak Farrokhzad-1/+2
2019-08-25Refactor feature gate checking codePascal Hertleif-18/+22
Tries to clarify the filtering of active features and make the code more expressive.
2019-08-25pprust: Do not print spaces before some tokensVadim Petrochenkov-1/+13
2019-08-25Introduce and use `Feature` type for feature gatesPascal Hertleif-23/+98
This replaces the ad-hoc tuples used in the different feature gate files and unifies their content into a common type, leading to more readable matches and other good stuff that comes from having named fields. It also contains the description of each feature as extracted from the doc comment.
2019-08-25parser: TopLevel -> RecoverComma.Mazdak Farrokhzad-10/+10
2019-08-25parser: gracefully handle `fn foo(A | B: type)`.Mazdak Farrokhzad-11/+41
2019-08-25Rollup merge of #63854 - c410-f3r:attrs-visit, r=petrochenkovMazdak Farrokhzad-81/+116
Modifies how Arg, Arm, Field, FieldPattern and Variant are visited Part of the necessary work to accomplish #63468.
2019-08-25parser: 'while parsing this or-pattern...'Mazdak Farrokhzad-1/+4
2019-08-25parser: simplify parse_pat_with_or_{inner}Mazdak Farrokhzad-17/+10
2019-08-24parser: reword || recovery.Mazdak Farrokhzad-1/+1
2019-08-24parser: extract recover_inner_leading_vert.Mazdak Farrokhzad-4/+7
2019-08-24parse_top_pat: silence leading vert gating sometimes.Mazdak Farrokhzad-3/+15
2019-08-24parser: bool -> TopLevel.Mazdak Farrokhzad-5/+9
2019-08-24parser: bool -> GateOr.Mazdak Farrokhzad-10/+16
2019-08-24parser: better recovery for || in inner pats.Mazdak Farrokhzad-4/+23
2019-08-24parser: drive-by: simplify `parse_arg_general`.Mazdak Farrokhzad-6/+3
2019-08-24parser: `let` stmts & `for` exprs: allow or-patterns.Mazdak Farrokhzad-8/+2
2019-08-24parser: document `parse_pat`.Mazdak Farrokhzad-0/+4
2019-08-24parser: `parse_pats` -> `parse_top_pat{_unpack}`.Mazdak Farrokhzad-16/+24
2019-08-24parser: document `ban_unexpected_or_or`.Mazdak Farrokhzad-0/+1
2019-08-24parser: move `maybe_recover_unexpected_comma` to a more appropriate place.Mazdak Farrokhzad-50/+49
2019-08-24parser: use `eat_or_separator` for leading vert.Mazdak Farrokhzad-2/+2
2019-08-24parser: improve `parse_pat_with_or` docs.Mazdak Farrokhzad-1/+2
2019-08-24parser: extract `eat_or_separator`.Mazdak Farrokhzad-30/+28
2019-08-24parser: integrate `maybe_recover_unexpected_comma` in `parse_pat_with_or`.Mazdak Farrokhzad-9/+17
2019-08-24parser: extract `maybe_recover_unexpected_comma`.Mazdak Farrokhzad-31/+36
2019-08-24parser: simplify `parse_pat_with_or`.Mazdak Farrokhzad-1/+1
2019-08-24parser: improve or-patterns recovery.Mazdak Farrokhzad-4/+11
2019-08-24parser: refactor `parse_pat_with_or` + use it in [p0, p1, ..] pats.Mazdak Farrokhzad-8/+15
2019-08-24parser: type alias `type Expected = Option<&'static str>;`.Mazdak Farrokhzad-8/+7
2019-08-24parser: extract `ban_unexpected_or_or`.Mazdak Farrokhzad-11/+13