about summary refs log tree commit diff
path: root/src/libsyntax
AgeCommit message (Collapse)AuthorLines
2019-10-08Optimize `TokenStreamBuilder::push`.Nicholas Nethercote-51/+43
Currently, when two tokens must be glued together, this function duplicates large chunks of the existing streams. This can cause quadratic behaviour. This commit changes the function so that it overwrites the last token with a glued token, which avoids the quadratic behaviour. This removes the need for `TokenStreamBuilder::push_all_but_{first,last}_tree`. The commit also restructures `push` somewhat, by removing `TokenStream::{first_tree_and_joint,last_tree_if_joint}` in favour of more pattern matching and some comments. This makes the code shorter, and in my opinion, more readable.
2019-10-08Optimize `TokenStream::from_streams`.Nicholas Nethercote-10/+37
Currently, this function creates a new empty stream, and then appends the elements from each given stream onto that stream. This can cause quadratic behaviour. This commit changes the function so that it modifies the first stream (which can be long) by extending it with the elements from the subsequent streams (which are almost always short), which avoids the quadratic behaviour.
2019-10-08Rollup merge of #65040 - Centril:items-cleanup, r=estebankMazdak Farrokhzad-214/+198
syntax: more cleanups in item and function signature parsing Follow up to https://github.com/rust-lang/rust/pull/64910. Best read commit-by-commit. r? @estebank
2019-10-07Warn if include macro fails to include entire fileMark Rousskov-0/+1
2019-10-07Mark #![feature(track_caller)] as incomplete.Adam Perry-0/+1
2019-10-07track_caller feature gate starts in 1.40.0.Adam Perry-1/+1
Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>
2019-10-07track_caller run-pass test, lint cleanup, PR review.Adam Perry-5/+2
2019-10-07[RFC 2091] Add #[track_caller] attribute.Ayose-0/+7
- The attribute is behind a feature gate. - Error if both #[naked] and #[track_caller] are applied to the same function. - Error if #[track_caller] is applied to a non-function item. - Error if ABI is not "rust" - Error if #[track_caller] is applied to a trait function. Error codes and descriptions are pending.
2019-10-07Fix compilation error after rebase.Charles Lew-1/+1
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-07Address review comments.Charles Lew-4/+3
2019-10-07Add feature gate for raw_dylib.Charles Lew-1/+10
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/+49
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-05Rollup merge of #64909 - estebank:turbofish-reloaded, r=CentrilTyler Mandry-14/+153
When encountering chained operators use heuristics to recover from bad turbofish
2019-10-05Account for macro invocation in `let mut $pat` diagnostic.Mazdak Farrokhzad-1/+5
2019-10-03Rollup merge of #65055 - GuillaumeGomez:long-err-explanation-E0556, ↵Tyler Mandry-1/+19
r=petrochenkov Add long error explanation for E0556 Part of #61137
2019-10-03Rollup merge of #64690 - petrochenkov:mixed, r=dtolnayTyler Mandry-0/+11
proc_macro API: Expose `macro_rules` hygiene Proc macros do not have direct access to our oldest and most stable hygiene kind - `macro_rules` hygiene. To emulate it macro authors have to go through two steps - first generate a temporary `macro_rules` item (using a derive, at least until https://github.com/rust-lang/rust/pull/64035 is merged), then generate a macro call to that item. Popular crates like [proc_macro_hack](https://crates.io/crates/proc-macro-hack) use this trick to generate hygienic identifiers from proc macros. I'd say that these workarounds with nested macro definitions have more chances to hit some corner cases in our hygiene system, in which we don't have full confidence. So, let's provide a direct access to `macro_rules` hygiene instead. This PR does that by adding a new method `Span::mixed_site` (bikeshedding is welcome) in addition to existing `Span::call_site` (stable) and `Span::def_site` (unstable). Identifiers with this span resolve at def-site in for local variables, labels and `$crate`, and resolve at call-site for everything else, i.e. exactly like identifiers produced by `macro_rules`. This API addition opens the way to stabilizing proc macros in expression positions (https://github.com/rust-lang/rust/issues/54727), for which use of call-site hygiene or workarounds with temporary items would be quite unfortunate. (`macro_rules` expanded in expression position, on the other hand, are stable since 1.0 and widely used.) r? @dtolnay @alexcrichton
2019-10-03Rollup merge of #64675 - Centril:deprecate-plugin, r=oli-obkTyler Mandry-4/+17
Deprecate `#![plugin]` & `#[plugin_registrar]` This PR deprecates `#![plugin]` and `#[plugin_registrar]`. ~A removal deadline is set: 1.44.0. This will be in 9 months from now and should give everyone who is still relying on the feature ample time to rid themselves of this dependency.~ cc https://github.com/rust-lang/rust/issues/29597 r? @Mark-Simulacrum
2019-10-03review commentsEsteban Küber-25/+32
2019-10-03review commentsEsteban Küber-20/+17
2019-10-03review commentsEsteban Küber-36/+43
2019-10-03Account for missing turbofish in paths tooEsteban Küber-4/+43
2019-10-03review commentsEsteban Küber-38/+49
2019-10-03When encountering chained operators use heuristics to recover from bad turbofishEsteban Küber-13/+91
2019-10-03Add long error explanation for E0556Guillaume Gomez-1/+19
2019-10-03proc_macro: Add `Span::mixed_site` exposing `macro_rules` hygieneVadim Petrochenkov-0/+11
2019-10-03plugin_registrary: use normal deprecation instead of hard coded warning.Mazdak Farrokhzad-6/+10
2019-10-03Deprecate `#![plugin]` and `#[plugin_registrar]`.Mazdak Farrokhzad-3/+12
2019-10-02syntax: improve parameter without type suggestionsDavid Wood-8/+25
This commit improves the suggestions provided when function parameters do not have types: - A new suggestion is added for arbitrary self types, which suggests adding `self: ` before the type. - Existing suggestions are now provided when a `<` is found where a `:` was expected (previously only `,` and `)` or trait items), this gives suggestions in the case where the unnamed parameter type is generic in a free function. - The suggestion that a type name be provided (e.g. `fn foo(HashMap<u32>)` -> `fn foo(HashMap: TypeName<u32>)`) will no longer occur when a `<` was found instead of `:`. - The ident will not be used for recovery when a `<` was found instead of `:`. Signed-off-by: David Wood <david@davidtw.co>
2019-10-02Add missing 'bump'Aaron Hill-0/+1
2019-10-02Add support for 'extern const fn'Aaron Hill-19/+48
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-563/+495
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-01Add E0551 long error explanationGuillaume Gomez-1/+19
2019-10-01Rollup merge of #64907 - alexreg:tidy-up, r=Mark-SimulacrumMazdak Farrokhzad-1/+1
A small amount of tidying-up factored out from PR #64648 As requested by @Mark-Simulacrum, I put this in a separate commit to make it easier to review. (As far as I can tell, no violations of the policy here, and they are simply in a separate PR because they're not directly related to the import of that PR.) r? @Mark-Simulacrum
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-01Rollup merge of #63931 - petrochenkov:stabmac, r=CentrilMazdak Farrokhzad-20/+8
Stabilize macros in some more positions - Fn-like macros and attribute macros in `extern` blocks - Fn-like procedural macros in type positions - ~Attribute macros on inline modules~ (moved to https://github.com/rust-lang/rust/pull/64273) Stabilization report: https://github.com/rust-lang/rust/pull/63931#issuecomment-526362396. Closes https://github.com/rust-lang/rust/issues/49476 cc https://github.com/rust-lang/rust/issues/54727
2019-10-01Rollup merge of #63674 - petrochenkov:meta2, r=CentrilMazdak Farrokhzad-65/+93
syntax: Support modern attribute syntax in the `meta` matcher Where "modern" means https://github.com/rust-lang/rust/pull/57367: ``` PATH PATH `(` TOKEN_STREAM `)` PATH `[` TOKEN_STREAM `]` PATH `{` TOKEN_STREAM `}` ``` Unfortunately, `meta` wasn't future-proofed using the `FOLLOW` token set like other matchers (https://github.com/rust-lang/rust/issues/34011), so code like `$meta:meta {` or `$meta:meta [` may break, and we need a crater run to find out how often this happens in practice. Closes https://github.com/rust-lang/rust/issues/49629 (by fully supporting `meta` rather than removing it.)
2019-10-01syntax: reformat passing of `FnHeader` to `parse_item_fn`.Mazdak Farrokhzad-12/+16
2019-10-01syntax: de-closure-ify `check_or_expected`.Mazdak Farrokhzad-7/+7
2019-10-01syntax: merge things back into `parse_visibility`.Mazdak Farrokhzad-37/+25
2019-10-01syntax: put helpers of `parse_self_param` in the method.Mazdak Farrokhzad-58/+57
2019-10-01syntax: document some methods.Mazdak Farrokhzad-2/+6
2019-10-01Address review commentsVadim Petrochenkov-2/+3
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-03-02 13:19:12 +0000