summary refs log tree commit diff
path: root/src/libsyntax
AgeCommit message (Collapse)AuthorLines
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
2019-08-24Modifies how Arg, Arm, Field, FieldPattern and Variant are visitedCaio-81/+116
Part of the necessary work to accomplish #63468.
2019-08-24Use doc comments for feature gate descriptionsPascal Hertleif-261/+284
This is just in preparation for future usage of these texts.
2019-08-24Auto merge of #63823 - petrochenkov:noapply2, r=matthewjasperbors-78/+71
Audit uses of `apply_mark` in built-in macros + Remove default macro transparencies Every use of `apply_mark` in a built-in or procedural macro is supposed to look like this ```rust location.with_ctxt(SyntaxContext::root().apply_mark(ecx.current_expansion.id)) ``` where `SyntaxContext::root()` means that the built-in/procedural macro is defined directly, rather than expanded from some other macro. However, few people understood what `apply_mark` does, so we had a lot of copy-pasted uses of it looking e.g. like ```rust span = span.apply_mark(ecx.current_expansion.id); ``` , which doesn't really make sense for procedural macros, but at the same time is not too harmful, if the macros use the traditional `macro_rules` hygiene. So, to fight this, we stop using `apply_mark` directly in built-in macro implementations, and follow the example of regular proc macros instead and use analogues of `Span::def_site()` and `Span::call_site()`, which are much more intuitive and less error-prone. - `ecx.with_def_site_ctxt(span)` takes the `span`'s location and combines it with a def-site context. - `ecx.with_call_site_ctxt(span)` takes the `span`'s location and combines it with a call-site context. Even if called multiple times (which sometimes happens due to some historical messiness of the built-in macro code) these functions will produce the same result, unlike `apply_mark` which will grow the mark chain further in this case. --- After `apply_mark`s in built-in macros are eliminated, the remaining `apply_mark`s are very few in number, so we can start passing the previously implicit `Transparency` argument to them explicitly, thus eliminating the need in `default_transparency` fields in hygiene structures and `#[rustc_macro_transparency]` annotations on built-in macros. So, the task of making built-in macros opaque can now be formulated as "eliminate `with_legacy_ctxt` in favor of `with_def_site_ctxt`" rather than "replace `#[rustc_macro_transparency = "semitransparent"]` with `#[rustc_macro_transparency = "opaque"]`". r? @matthewjasper
2019-08-23syntax: move `feature_gate.rs`.Mazdak Farrokhzad-0/+0
2019-08-23syntax: extract `check.rs`.Mazdak Farrokhzad-953/+960
2019-08-23builtin_attrs.rs: retain FIXMEs.Mazdak Farrokhzad-2/+6
2019-08-23builtin_attrs.rs: organize!Mazdak Farrokhzad-241/+259
2019-08-23builtin_attrs.rs: cleanup with `(un)gated!`.Mazdak Farrokhzad-288/+229
2019-08-23builtin_attrs.rs: refactor `rustc_attrs` entries.Mazdak Farrokhzad-233/+109
2019-08-23builtin_attrs.rs: simplify `cfg_fn`.Mazdak Farrokhzad-8/+7
2019-08-23syntax: extract `builin_attrs.rs`.Mazdak Farrokhzad-715/+732
2019-08-23syntax: extract `active.rs` feature gates.Mazdak Farrokhzad-517/+525
2019-08-23syntax: extract `removed.rs` feature gates.Mazdak Farrokhzad-77/+85
2019-08-23syntax: extract `accepted.rs` feature gates.Mazdak Farrokhzad-231/+239
2019-08-23Remove default macro transparenciesVadim Petrochenkov-21/+0
All transparancies are passed explicitly now. Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used. `#[rustc_macro_transparency]` only makes sense for declarative macros now.
2019-08-23hygiene: Require passing transparency explicitly to `apply_mark`Vadim Petrochenkov-41/+47
2019-08-23Audit uses of `apply_mark` in built-in macrosVadim Petrochenkov-17/+25
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API. The new API is much less error prone and doesn't rely on macros having default transparency.
2019-08-21fix rebaseEsteban Küber-1/+1
2019-08-21FormattingEsteban Küber-24/+45
2019-08-21Add terminal_width debugging flagEsteban Küber-7/+17
2019-08-21Rollup merge of #63717 - petrochenkov:eager, r=matthewjasperMazdak Farrokhzad-9/+8
Fix nested eager expansions in arguments of `format_args` Fixes https://github.com/rust-lang/rust/issues/63460 Fixes https://github.com/rust-lang/rust/issues/63685 (regression from making `format_args` opaque - https://github.com/rust-lang/rust/pull/63114) r? @matthewjasper
2019-08-21Rollup merge of #63762 - rust-lang:fix-async-date, r=Mark-SimulacrumMazdak Farrokhzad-1/+1
`async_await` was stabilized in 1.39.0, not 1.38.0. r? @Mark-Simulacrum
2019-08-21Rollup merge of #63759 - Centril:parse-default-async-fn, r=petrochenkovMazdak Farrokhzad-0/+1
Allow 'default async fn' to parse. - Parse default async fn. Fixes #63716. (`cherry-pick`ed from 3rd commit in https://github.com/rust-lang/rust/pull/63749.) r? @petrochenkov
2019-08-21Rollup merge of #63755 - Centril:simplify-prexp-gating, r=petrochenkovMazdak Farrokhzad-28/+34
Use dedicated type for spans in pre-expansion gating. - Simplify the overall pre-expansion gating "experience".
2019-08-21Rollup merge of #63721 - Mark-Simulacrum:decouple-error-index, r=matthewjasperMazdak Farrokhzad-124/+4
Do not emit JSON dumps of diagnostic codes This decouples the error index generator from libsyntax for the most part (though it still depends on librustdoc for the markdown parsing and generation). Fixes #34588
2019-08-21resolve/expand: Rename some things for clarity and add commentsVadim Petrochenkov-4/+7
2019-08-21expand: Do not do questionable span adjustment before eagerly expanding an ↵Vadim Petrochenkov-4/+1
expression Maybe it made sense when it was introduced, but now it's doing something incorrect.
2019-08-21expand: Keep the correct current expansion ID for eager expansionsVadim Petrochenkov-1/+0
Solve the problem of `ParentScope` entries for eager expansions not exising in the resolver map by creating them on demand.
2019-08-21async_await was stabilized in 1.39.0, not 1.38.0.Mazdak Farrokhzad-1/+1
2019-08-20Allow 'default async fn' to parse.Mazdak Farrokhzad-0/+1
2019-08-20Use dedicated type for spans in pre-expansion gating.Mazdak Farrokhzad-28/+34
2019-08-20Rollup merge of #63209 - Centril:stabilize-async-await, r=cramertjMazdak Farrokhzad-17/+2
Stabilize `async_await` in Rust 1.39.0 Here we stabilize: - free and inherent `async fn`s, - the `<expr>.await` expression form, - and the `async move? { ... }` block form. Closes https://github.com/rust-lang/rust/issues/62149. Closes https://github.com/rust-lang/rust/issues/50547. All the blockers are now closed. <details> - [x] FCP in https://github.com/rust-lang/rust/issues/62149 - [x] https://github.com/rust-lang/rust/issues/61949; PR in https://github.com/rust-lang/rust/pull/62849. - [x] https://github.com/rust-lang/rust/issues/62517; PR in https://github.com/rust-lang/rust/pull/63376. - [x] https://github.com/rust-lang/rust/issues/63225; PR in https://github.com/rust-lang/rust/pull/63501 - [x] https://github.com/rust-lang/rust/issues/63388; PR in https://github.com/rust-lang/rust/pull/63499 - [x] https://github.com/rust-lang/rust/issues/63500; PR in https://github.com/rust-lang/rust/pull/63501 - [x] https://github.com/rust-lang/rust/issues/62121#issuecomment-506884048 - [x] Some tests for control flow (PR https://github.com/rust-lang/rust/pull/63387): - `?` - `return` in `async` blocks - `break` - [x] https://github.com/rust-lang/rust/pull/61775#issuecomment-506883180, i.e. tests for https://github.com/rust-lang/rust/pull/60944 with `async fn`s instead). PR in https://github.com/rust-lang/rust/pull/63383 </details> r? @cramertj
2019-08-20Remove serialization of diagnostics to filesMark Rousskov-124/+4
This is no longer used by the index generator and was always an unstable compiler detail, so strip it out. This also leaves in RUSTC_ERROR_METADATA_DST since the stage0 compiler still needs it to be set.
2019-08-20Stabilize 'async_await'.Mazdak Farrokhzad-17/+2
2019-08-19glue tokens when building token streamAleksey Kladov-10/+34
2019-08-19remove composite tokens support from the lexerAleksey Kladov-37/+20
2019-08-18Auto merge of #62948 - matklad:failable-file-loading, r=petrochenkovbors-66/+15
Normalize newlines when loading files Fixes #62865
2019-08-18Auto merge of #61708 - dlrobertson:or-patterns-0, r=centrilbors-28/+80
Initial implementation of or-patterns An incomplete implementation of or-patterns (e.g. `Some(0 | 1)` as a pattern). This patch set aims to implement initial parsing of `or-patterns`. Related to: #54883 CC @alexreg @varkor r? @Centril
2019-08-17resolve/expand: Rename some things for clarityVadim Petrochenkov-19/+21
2019-08-17initial implementation of or-pattern parsingDan Robertson-40/+59
Initial implementation of parsing or-patterns e.g., `Some(Foo | Bar)`. This is a partial implementation of RFC 2535.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-11 22:04:06 +0000