about summary refs log tree commit diff
path: root/src/librustc_ast
AgeCommit message (Collapse)AuthorLines
2020-08-02Auto merge of #74826 - matklad:mbe-fragment, r=petrochenkovbors-0/+61
Introduce NonterminalKind for more type-safe mbe parsing It encapsulate the (part of) the interface between the parser and macro by example (macro_rules) parser. The second bit is somewhat more general `parse_ast_fragment`, which is the reason why we keep some `parse_xxx` functions as public.
2020-08-02Use NonterminalKind for MetaVarDeclAleksey Kladov-1/+24
This is more type safe and allows us to remove a few dead branches
2020-08-02Introduce NonterminalKindAleksey Kladov-0/+38
It encapsulate the (part of) the interface between the parser and macro by example (macro_rules) parser. The second bit is somewhat more general `parse_ast_fragment`, which is the reason why we keep some `parse_xxx` functions as public.
2020-08-01Move 'probably equal' methods to librustc_parseAaron Hill-181/+0
This is preparation for PR #73084
2020-07-31Move from `log` to `tracing`Oliver Scherer-1/+1
2020-07-22build: Remove unnecessary `cargo:rerun-if-env-changed` annotationsVadim Petrochenkov-5/+0
2020-07-16apply bootstrap cfgsMark Rousskov-2/+1
2020-07-15Remove lots of `Symbol::as_str()` calls.Nicholas Nethercote-36/+54
In various ways, such as changing functions to take a `Symbol` instead of a `&str`.
2020-07-15Add and use more static symbols.Nicholas Nethercote-7/+7
Note that the output of `unpretty-debug.stdout` has changed. In that test the hash values are normalized from a symbol numbers to small numbers like "0#0" and "0#1". The increase in the number of static symbols must have caused the original numbers to contain more digits, resulting in different pretty-printing prior to normalization.
2020-07-11Stabilize `transmute` in constants and statics but not const fnOliver Scherer-1/+1
2020-07-09Eliminate confusing "globals" terminology.Nicholas Nethercote-21/+27
There are some structures that are called "globals", but are they global to a compilation session, and not truly global. I have always found this highly confusing, so this commit renames them as "session globals" and adds a comment explaining things. Also, the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs`
2020-07-02Document rustc_ast::ast::Patpierwill-0/+3
2020-07-01Rollup merge of #73569 - Aaron1011:fix/macro-rules-group, r=petrochenkovManish Goregaokar-4/+14
Handle `macro_rules!` tokens consistently across crates When we serialize a `macro_rules!` macro, we used a 'lowered' `TokenStream` for its body, which has all `Nonterminal`s expanded in-place via `nt_to_tokenstream`. This matters when an 'outer' `macro_rules!` macro expands to an 'inner' `macro_rules!` macro - the inner macro may use tokens captured from the 'outer' macro in its definition. This means that invoking a foreign `macro_rules!` macro may use a different body `TokenStream` than when the same `macro_rules!` macro is invoked in the same crate. This difference is observable by proc-macros invoked by a `macro_rules!` macro - a `None`-delimited group will be seen in the same-crate case (inserted when convering `Nonterminal`s to the `proc_macro` crate's structs), but no `None`-delimited group in the cross-crate case. To fix this inconsistency, we now insert `None`-delimited groups when 'lowering' a `Nonterminal` `macro_rules!` body, just as we do in `proc_macro_server`. Additionally, we no longer print extra spaces for `None`-delimited groups - as far as pretty-printing is concerned, they don't exist (only their contents do). This ensures that `Display` output of a `TokenStream` does not depend on which crate a `macro_rules!` macro was invoked from. This PR is necessary in order to patch the `solana-genesis-programs` for the upcoming hygiene serialization breakage (https://github.com/rust-lang/rust/pull/72121#issuecomment-646924847). The `solana-genesis-programs` crate will need to use a proc macro to re-span certain tokens in a nested `macro_rules!`, which requires us to consistently use a `None`-delimited group. See `src/test/ui/proc-macro/nested-macro-rules.rs` for an example of the kind of nested `macro_rules!` affected by this crate.
2020-07-01Add an issue number for the pretty_printing_compatibility_hack FIXMEVadim Petrochenkov-1/+1
2020-07-01Insert NoDelim groups around nonterminals when lowering macro_rulesAaron Hill-4/+14
2020-07-01Remove `token::FlattenGroup`Vadim Petrochenkov-22/+13
2020-07-01expand: Stop using nonterminals for passing tokens to attribute and derive ↵Vadim Petrochenkov-1/+21
macros
2020-06-28Remove `const_if_match` feature gate from librariesDylan MacKenzie-1/+1
2020-06-26Rollup merge of #73629 - flip1995:assoc_op_copy_clone, r=ManishearthManish Goregaokar-1/+1
Make AssocOp Copy Found that this enum is not `Copy` while reviewing this Clippy PR: https://github.com/rust-lang/rust-clippy/pull/5727#discussion_r443761621 There shouldn't be a reason why this should not be `Copy`.
2020-06-26Rollup merge of #73597 - ayazhafiz:i/const-span, r=ecstatic-morseManish Goregaokar-1/+3
Record span of `const` kw in GenericParamKind Context: this is needed for a fix of https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-26proc_macro: Stop flattening groups with dummy spansVadim Petrochenkov-14/+23
2020-06-23Record span of `const` kw in GenericParamKindAyaz Hafiz-1/+3
Context: this is needed to fix https://github.com/rust-lang/rustfmt/issues/4263, which currently records the span of a const generic param incorrectly because the location of the `const` kw is not known. I am not sure how to add tests for this; any guidance in how to do so would be appreciated :slightly_smiling_face:
2020-06-22Make AssocOp Copyflip1995-1/+1
2020-06-19Rollup merge of #73364 - joshtriplett:inline-asm, r=AmanieuManish Goregaokar-1/+1
asm: Allow multiple template string arguments; interpret them as newline-separated Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument. This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`. For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings: ```rust fn main() { let mut bits = [0u8; 64]; for value in 0..=1024u64 { let popcnt; unsafe { asm!( " popcnt {popcnt}, {v}", "2:", " blsi rax, {v}", " jz 1f", " xor {v}, rax", " tzcnt rax, rax", " stosb", " jmp 2b", "1:", v = inout(reg) value => _, popcnt = out(reg) popcnt, out("rax") _, // scratch inout("rdi") bits.as_mut_ptr() => _, ); } println!("bits of {}: {:?}", value, &bits[0..popcnt]); } } ``` Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
2020-06-16Fix typo in librustc_ast docspierwill-1/+1
Fixed sentence by removing a word.
2020-06-14asm: When pretty-printing, don't escape characters twiceJosh Triplett-1/+1
pprust uses `print_string` to write out the template string, and `print_string` already calls `escape_debug`, so `impl fmt::Display for InlineAsmTemplatePiece` shouldn't do an additional `escape_debug`. This fixes a pretty-printing bug that translated `asm!("...\n...")` to `asm!("...\\n...")`
2020-06-15Auto merge of #72080 - matthewjasper:uniform-impl-trait, r=nikomatsakisbors-9/+0
Clean up type alias impl trait implementation - Removes special case for top-level impl trait - Removes associated opaque types - Forbid lifetime elision in let position impl trait. This is consistent with the behavior for inferred types. - Handle lifetimes in type alias impl trait more uniformly with other parameters cc #69323 cc #63063 Closes #57188 Closes #62988 Closes #69136 Closes #73061
2020-06-11Rollup merge of #73182 - Aaron1011:feature/call-fn-span, r=matthewjasperDylan DPC-4/+7
Track span of function in method calls, and use this in #[track_caller] Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()`, each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics, it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call`, where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example, see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
2020-06-11Stop special casing top level TAITMatthew Jasper-9/+0
2020-06-11Rollup merge of #73172 - matthiaskrgr:cl9ppy, r=Dylan-DPCDylan DPC-1/+1
Fix more clippy warnings Fixes more of: clippy::unused_unit clippy::op_ref clippy::useless_format clippy::needless_return clippy::useless_conversion clippy::bind_instead_of_map clippy::into_iter_on_ref clippy::redundant_clone clippy::nonminimal_bool clippy::redundant_closure clippy::option_as_ref_deref clippy::len_zero clippy::iter_cloned_collect clippy::filter_next r? @Dylan-DPC
2020-06-10Add doc commentsAaron Hill-1/+1
2020-06-10Track span of function in method calls, and use this in #[track_caller]Aaron Hill-4/+7
Fixes #69977 When we parse a chain of method calls like `foo.a().b().c()`, each `MethodCallExpr` gets assigned a span that starts at the beginning of the call chain (`foo`). While this is useful for diagnostics, it means that `Location::caller` will return the same location for every call in a call chain. This PR makes us separately record the span of the function name and arguments for a method call (e.g. `b()` in `foo.a().b().c()`). This `Span` is passed through HIR lowering and MIR building to `TerminatorKind::Call`, where it is used in preference to `Terminator.source_info.span` when determining `Location::caller`. This new span is also useful for diagnostics where we want to emphasize a particular method call - for an example, see https://github.com/rust-lang/rust/pull/72389#discussion_r436035990
2020-06-09Fix more clippy warningsMatthias Krüger-1/+1
Fixes more of: clippy::unused_unit clippy::op_ref clippy::useless_format clippy::needless_return clippy::useless_conversion clippy::bind_instead_of_map clippy::into_iter_on_ref clippy::redundant_clone clippy::nonminimal_bool clippy::redundant_closure clippy::option_as_ref_deref clippy::len_zero clippy::iter_cloned_collect clippy::filter_next
2020-06-08Don't lose empty `where` clause when pretty-printingAaron Hill-2/+11
Previously, we would parse `struct Foo where;` and `struct Foo;` identically, leading to an 'empty' `where` clause being omitted during pretty printing. This will cause us to lose spans when proc-macros involved, since we will have a collected `where` token that does not appear in the pretty-printed item. We now explicitly track the presence of a `where` token during parsing, so that we can distinguish between `struct Foo where;` and `struct Foo;` during pretty-printing
2020-06-02Make things build againVadim Petrochenkov-1/+1
2020-05-30Rollup merge of #72625 - Amanieu:asm-srcloc, r=petrochenkovRalf Jung-1/+2
Improve inline asm error diagnostics Previously we were just using the raw LLVM error output (with line, caret, etc) as the diagnostic message, which ends up looking rather out of place with our existing diagnostics. The new diagnostics properly format the diagnostics and also take advantage of LLVM's per-line `srcloc` attribute to map an error in inline assembly directly to the relevant line of source code. Incidentally also fixes #71639 by disabling `srcloc` metadata during LTO builds since we don't know what crate it might have come from. We can only resolve `srcloc`s from the currently crate since it indexes into the source map for the current crate. Fixes #72664 Fixes #71639 r? @petrochenkov ### Old style ```rust #![feature(llvm_asm)] fn main() { unsafe { let _x: i32; llvm_asm!( "mov $0, $1 invalid_instruction $0, $1 mov $0, $1" : "=&r" (_x) : "r" (0) :: "intel" ); } } ``` ``` error: <inline asm>:3:14: error: invalid instruction mnemonic 'invalid_instruction' invalid_instruction ecx, eax ^~~~~~~~~~~~~~~~~~~ --> src/main.rs:6:9 | 6 | / llvm_asm!( 7 | | "mov $0, $1 8 | | invalid_instruction $0, $1 9 | | mov $0, $1" ... | 12 | | :: "intel" 13 | | ); | |__________^ ``` ### New style ```rust #![feature(asm)] fn main() { unsafe { asm!( "mov {0}, {1} invalid_instruction {0}, {1} mov {0}, {1}", out(reg) _, in(reg) 0i64, ); } } ``` ``` error: invalid instruction mnemonic 'invalid_instruction' --> test.rs:7:14 | 7 | invalid_instruction {0}, {1} | ^ | note: instantiated into assembly here --> <inline asm>:3:14 | 3 | invalid_instruction rax, rcx | ^^^^^^^^^^^^^^^^^^^ ```
2020-05-29Improve inline asm error diagnosticsAmanieu d'Antras-1/+2
2020-05-29Revert "Move functions to librustc_parse"Aaron Hill-0/+177
This reverts commit 7a4c1865fb2f58c57e3f09645515dec8be3022c6.
2020-05-29Revert "Recursively expand nonterminals"Aaron Hill-0/+2
This reverts commit 2af0218bf1ffca0750a352554f20a07b760a30a8.
2020-05-29Revert "Fix rebase fallout"Aaron Hill-0/+2
This reverts commit 5685e4dd90ad2f4978c63b9097f0b568e4ce6e5c.
2020-05-24Collect tokens for `ast::Expr`Aaron Hill-2/+6
2020-05-22Fix rebase falloutAaron Hill-2/+0
2020-05-22Recursively expand nonterminalsAaron Hill-2/+0
2020-05-22Move functions to librustc_parseAaron Hill-177/+0
2020-05-19Use a fixed-point iteration when breaking tokensAaron Hill-5/+40
Some tokens need to be broken in a loop until we reach 'unbreakable' tokens.
2020-05-19Break tokens before checking if they are 'probably equal'Aaron Hill-2/+32
Fixes #68489 When checking two `TokenStreams` to see if they are 'probably equal', we ignore the `IsJoint` information associated with each `TokenTree`. However, the `IsJoint` information determines whether adjacent tokens will be 'glued' (if possible) when construction the `TokenStream` - e.g. `[Gt Gt]` can be 'glued' to `BinOp(Shr)`. Since we are ignoring the `IsJoint` information, 'glued' and 'unglued' tokens are equivalent for determining if two `TokenStreams` are 'probably equal'. Therefore, we need to 'unglue' all tokens in the stream to avoid false negatives (which cause us to throw out the cached tokens, losing span information).
2020-05-18Move InlineAsmTemplatePiece and InlineAsmOptions to librustc_astAmanieu d'Antras-2/+55
2020-05-18Add asm! to ASTAmanieu d'Antras-1/+99
2020-05-16Rollup merge of #72047 - ↵Ralf Jung-33/+42
Julian-Wollersberger:literal_error_reporting_cleanup, r=petrochenkov Literal error reporting cleanup While doing some performance work, I noticed some code duplication in `librustc_parser/lexer/mod.rs`, so I cleaned it up. This PR is probably best reviewed commit by commit. I'm not sure what the API stability practices for `librustc_lexer` are. Four public methods in `unescape.rs` can be removed, but two are used by clippy, so I left them in for now. I could open a PR for Rust-Analyzer when this one lands. But how do I open a PR for clippy? (Git submodules are frustrating to work with)
2020-05-13Replace some usages of the old `unescape_` functions in AST, clippy and tests.Julian Wollersberger-33/+42
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 23:20:33 +0000