summary refs log tree commit diff
path: root/compiler/rustc_expand/src/base.rs
AgeCommit message (Collapse)AuthorLines
2022-09-07ssa: implement `#[collapse_debuginfo]`David Wood-16/+23
Debuginfo line information for macro invocations are collapsed by default - line information are replaced by the line of the outermost expansion site. Using `-Zdebug-macros` disables this behaviour. When the `collapse_debuginfo` feature is enabled, the default behaviour is reversed so that debuginfo is not collapsed by default. In addition, the `#[collapse_debuginfo]` attribute is available and can be applied to macro definitions which will then have their line information collapsed. Signed-off-by: David Wood <david.wood@huawei.com>
2022-08-23Remove the symbol from `ast::LitKind::Err`.Nicholas Nethercote-1/+1
Because it's never used meaningfully.
2022-08-22Use `AttrVec` in more places.Nicholas Nethercote-2/+2
In some places we use `Vec<Attribute>` and some places we use `ThinVec<Attribute>` (a.k.a. `AttrVec`). This results in various points where we have to convert between `Vec` and `ThinVec`. This commit changes the places that use `Vec<Attribute>` to use `AttrVec`. A lot of this is mechanical and boring, but there are some interesting parts: - It adds a few new methods to `ThinVec`. - It implements `MapInPlace` for `ThinVec`, and introduces a macro to avoid the repetition of this trait for `Vec`, `SmallVec`, and `ThinVec`. Overall, it makes the code a little nicer, and has little effect on performance. But it is a precursor to removing `rustc_data_structures::thin_vec::ThinVec` and replacing it with `thin_vec::ThinVec`, which is implemented more efficiently.
2022-07-26Implement `#[rustc_default_body_unstable]`Maybe Waffle-1/+12
This attribute allows to mark default body of a trait function as unstable. This means that implementing the trait without implementing the function will require enabling unstable feature. This is useful in conjunction with `#[rustc_must_implement_one_of]`, we may want to relax requirements for a trait, for example allowing implementing either of `PartialEq::{eq, ne}`, but do so in a safe way -- making implementation of only `PartialEq::ne` unstable.
2022-07-16rustc_expand: Switch FxHashMap to FxIndexMap where iteration is usedNiklas Jonsson-3/+3
2022-07-13Emit warning when named arguments are used positionally in formatPreston From-1/+4
Addresses Issue 98466 by emitting a warning if a named argument is used like a position argument (i.e. the name is not used in the string to be formatted). Fixes rust-lang#98466
2022-07-01update cfg(bootstrap)sPietro Albini-3/+3
2022-06-27various: add `rustc_lint_diagnostics` to diag fnsDavid Wood-0/+3
The `rustc_lint_diagnostics` attribute is used by the diagnostic translation/struct migration lints to identify calls where non-translatable diagnostics or diagnostics outwith impls are being created. Any function used in creating a diagnostic should be annotated with this attribute so this commit adds the attribute to many more functions. Signed-off-by: David Wood <david.wood@huawei.com>
2022-06-21Add `create_err` and `emit_err` to `ExtCtxt`beetrees-1/+12
2022-06-13remove unnecessary `to_string` and `String::new`Takayuki Maeda-1/+1
2022-05-27Rename `ProcMacro` trait as `BangProcMacro`.Nicholas Nethercote-3/+3
Similar to the existing `AttrProcMacro` trait.
2022-05-22rustc_parse: Move AST -> TokenStream conversion logic to `rustc_ast`Vadim Petrochenkov-10/+8
2022-05-20Remove `crate` visibility usage in compilerJacob Pratt-1/+1
2022-05-12Auto merge of #96150 - est31:unused_macro_rules, r=petrochenkovbors-0/+2
Implement a lint to warn about unused macro rules This implements a new lint to warn about unused macro rules (arms/matchers), similar to the `unused_macros` lint added by #41907 that warns about entire macros. ```rust macro_rules! unused_empty { (hello) => { println!("Hello, world!") }; () => { println!("empty") }; //~ ERROR: 1st rule of macro `unused_empty` is never used } fn main() { unused_empty!(hello); } ``` Builds upon #96149 and #96156. Fixes #73576
2022-05-11ast: Introduce some traits to get AST node properties genericallyVadim Petrochenkov-24/+38
And use them to avoid constructing some artificial `Nonterminal` tokens during expansion
2022-05-05Implement the unused_macro_rules lintest31-0/+2
2022-05-03Add support for a new attribute `#[debugger_visualizer]` to support ↵ridwanabdillahi-2/+39
embedding debugger visualizers into a generated PDB. Cleanup `DebuggerVisualizerFile` type and other minor cleanup of queries. Merge the queries for debugger visualizers into a single query. Revert move of `resolve_path` to `rustc_builtin_macros`. Update dependencies in Cargo.toml for `rustc_passes`. Respond to PR comments. Load visualizer files into opaque bytes `Vec<u8>`. Debugger visualizers for dynamically linked crates should not be embedded in the current crate. Update the unstable book with the new feature. Add the tracking issue for the debugger_visualizer feature. Respond to PR comments and minor cleanups.
2022-04-27tut tut tutEllen-3/+1
2022-04-09Auto merge of #95697 - klensy:no-strings, r=petrochenkovbors-2/+2
refactor: simplify few string related interactions Few small optimizations: check_doc_keyword: don't alloc string for emptiness check check_doc_alias_value: get argument as Symbol to prevent needless string convertions check_doc_attrs: don't alloc vec, iterate over slice. replace as_str() check with symbol check get_single_str_from_tts: don't prealloc string trivial string to str replace LifetimeScopeForPath::NonElided use Vec<Symbol> instead of Vec<String> AssertModuleSource use FxHashSet<Symbol> instead of BTreeSet<String> CrateInfo.crate_name replace FxHashMap<CrateNum, String> with FxHashMap<CrateNum, Symbol>
2022-04-08check_doc_keyword: don't alloc string for emptiness checkklensy-2/+2
check_doc_alias_value: get argument as Symbol to prevent needless string convertions check_doc_attrs: don't alloc vec, iterate over slice. Vec introduced in #83149, but no perf run posted on merge replace as_str() check with symbol check get_single_str_from_tts: don't prealloc string trivial string to str replace LifetimeScopeForPath::NonElided use Vec<Symbol> instead of Vec<String> AssertModuleSource use BTreeSet<Symbol> instead of BTreeSet<String> CrateInfo.crate_name replace FxHashMap<CrateNum, String> with FxHashMap<CrateNum, Symbol>
2022-04-07Shrink `Nonterminal`.Nicholas Nethercote-1/+1
By heap allocating the argument within `NtPath`, `NtVis`, and `NtStmt`. This slightly reduces cumulative and peak allocation amounts, most notably on `deep-vector`.
2022-04-05Rollup merge of #95473 - lqd:macro-expansion, r=petrochenkovDylan DPC-0/+6
track individual proc-macro expansions in the self-profiler As described in [this zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Macro.20expansion.20performance.20on.20complex.20macros/near/275063190), users don't currently have a lot of information to diagnose macro expansion performance issues. That comment suggests using the macro names to add further timing information. This PR starts to do this for proc-macros which have the same issue, and performance problems happening in the wild in [this other zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Identifying.20proc-macro.20slowdowns) could be helped by such information. It uses the available proc-macro name to track their individual expansions with self-profiling events. r? `@Aaron1011` who mentioned this idea originally
2022-04-05track proc-macro expansions in the self-profilerRémy Rakic-0/+6
Use the proc-macro descr to track their individual expansions with self-profiling events. This will help diagnose performance issues with slow proc-macros.
2022-04-05span: move `MultiSpan`David Wood-2/+2
`MultiSpan` contains labels, which are more complicated with the introduction of diagnostic translation and will use types from `rustc_errors` - however, `rustc_errors` depends on `rustc_span` so `rustc_span` cannot use types like `DiagnosticMessage` without dependency cycles. Introduce a new `rustc_error_messages` crate that can contain `DiagnosticMessage` and `MultiSpan`. Signed-off-by: David Wood <david.wood@huawei.com>
2022-03-26Move resolve_path to rustc_builtin_macros and make it privateBadel2-37/+2
2022-03-16rustc_error: make ErrorReported impossible to constructmark-1/+1
There are a few places were we have to construct it, though, and a few places that are more invasive to change. To do this, we create a constructor with a long obvious name.
2022-03-03Associate multiple with a crate too.Felix S. Klock II-1/+1
2022-03-02rename ErrorReported -> ErrorGuaranteedmark-7/+7
2022-02-23rustc_errors: let `DiagnosticBuilder::emit` return a "guarantee of emission".Eduard-Mihai Burtescu-9/+11
2022-02-19Adopt let else in more placesest31-15/+8
2022-01-23expand: Pass everything by reference to pre-expansion lint callbackVadim Petrochenkov-10/+18
2022-01-23rustc_lint: Stop creating a fake `ast::Crate` for running early lintsVadim Petrochenkov-2/+3
Add a trait generalizing over the crate root and freshly loaded modules instead This also makes node IDs used for pre-expansion linting more precise
2022-01-23rustc_lint: Reuse the set of registered tools from resolverVadim Petrochenkov-1/+4
2021-11-28expand: Turn `ast::Crate` into a first class expansion targetVadim Petrochenkov-1/+18
And stop creating a fake `mod` item for the crate root when expanding a crate.
2021-09-11Auto merge of #84373 - cjgillot:resolve-span, r=michaelwoerister,petrochenkovbors-1/+2
Encode spans relative to the enclosing item The aim of this PR is to avoid recomputing queries when code is moved without modification. MCP at https://github.com/rust-lang/compiler-team/issues/443 This is achieved by : 1. storing the HIR owner LocalDefId information inside the span; 2. encoding and decoding spans relative to the enclosing item in the incremental on-disk cache; 3. marking a dependency to the `source_span(LocalDefId)` query when we translate a span from the short (`Span`) representation to its explicit (`SpanData`) representation. Since all client code uses `Span`, step 3 ensures that all manipulations of span byte positions actually create the dependency edge between the caller and the `source_span(LocalDefId)`. This query return the actual absolute span of the parent item. As a consequence, any source code motion that changes the absolute byte position of a node will either: - modify the distance to the parent's beginning, so change the relative span's hash; - dirty `source_span`, and trigger the incremental recomputation of all code that depends on the span's absolute byte position. With this scheme, I believe the dependency tracking to be accurate. For the moment, the spans are marked during lowering. I'd rather do this during def-collection, but the AST MutVisitor is not practical enough just yet. The only difference is that we attach macro-expanded spans to their expansion point instead of the macro itself.
2021-09-10Record call_site parent for macros.Camille GILLOT-1/+2
2021-09-10Rollup merge of #87441 - ibraheemdev:i-86865, r=cjgillotManish Goregaokar-7/+22
Emit suggestion when passing byte literal to format macro Closes #86865
2021-09-03Auto merge of #88597 - cjgillot:lower-global, r=petrochenkovbors-0/+8
Move global analyses from lowering to resolution Split off https://github.com/rust-lang/rust/pull/87234 r? `@petrochenkov`
2021-09-01Compute proc_macros in resolutions.Camille GILLOT-0/+8
2021-08-31emit suggestion byte literal is passed to `format!`ibraheemdev-7/+22
2021-08-27Path remapping: Make behavior of diagnostics output dependent on presence of ↵Michael Woerister-1/+1
--remap-path-prefix.
2021-08-21Remove `NonMacroAttr.mark_used`Aaron Hill-7/+4
2021-08-15Introduce hir::ExprKind::Let - Take 2Caio-0/+1
2021-07-25Auto merge of #87381 - Aaron1011:note-semi-trailing-macro, r=petrochenkovbors-0/+2
Display an extra note for trailing semicolon lint with trailing macro Currently, we parse macros at the end of a block (e.g. `fn foo() { my_macro!() }`) as expressions, rather than statements. This means that a macro invoked in this position cannot expand to items or semicolon-terminated expressions. In the future, we might want to start parsing these kinds of macros as statements. This would make expansion more 'token-based' (i.e. macro expansion behaves (almost) as if you just textually replaced the macro invocation with its output). However, this is a breaking change (see PR #78991), so it will require further discussion. Since the current behavior will not be changing any time soon, we need to address the interaction with the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint. Since we are parsing the result of macro expansion as an expression, we will emit a lint if there's a trailing semicolon in the macro output. However, this results in a somewhat confusing message for users, since it visually looks like there should be no problem with having a semicolon at the end of a block (e.g. `fn foo() { my_macro!() }` => `fn foo() { produced_expr; }`) To help reduce confusion, this commit adds a note explaining that the macro is being interpreted as an expression. Additionally, we suggest adding a semicolon after the macro *invocation* - this will cause us to parse the macro call as a statement. We do *not* use a structured suggestion for this, since the user may actually want to remove the semicolon from the macro definition (allowing the block to evaluate to the expression produced by the macro).
2021-07-24Display an extra note for trailing semicolon lint with trailing macroAaron Hill-0/+2
Currently, we parse macros at the end of a block (e.g. `fn foo() { my_macro!() }`) as expressions, rather than statements. This means that a macro invoked in this position cannot expand to items or semicolon-terminated expressions. In the future, we might want to start parsing these kinds of macros as statements. This would make expansion more 'token-based' (i.e. macro expansion behaves (almost) as if you just textually replaced the macro invocation with its output). However, this is a breaking change (see PR #78991), so it will require further discussion. Since the current behavior will not be changing any time soon, we need to address the interaction with the `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` lint. Since we are parsing the result of macro expansion as an expression, we will emit a lint if there's a trailing semicolon in the macro output. However, this results in a somewhat confusing message for users, since it visually looks like there should be no problem with having a semicolon at the end of a block (e.g. `fn foo() { my_macro!() }` => `fn foo() { produced_expr; }`) To help reduce confusion, this commit adds a note explaining that the macro is being interpreted as an expression. Additionally, we suggest adding a semicolon after the macro *invocation* - this will cause us to parse the macro call as a statement. We do *not* use a structured suggestion for this, since the user may actually want to remove the semicolon from the macro definition (allowing the block to evaluate to the expression produced by the macro).
2021-07-23Rename `known_attrs` to `expanded_inert_attrs` and move to rustc_expandAaron Hill-0/+6
There's no need for this to be (untracked) global state.
2021-07-17Only use `assign_id!` for ast nodes that support attributesAaron Hill-0/+3
2021-07-17Compute a better `lint_node_id` during expansionAaron Hill-3/+3
When we need to emit a lint at a macro invocation, we currently use the `NodeId` of its parent definition (e.g. the enclosing function). This means that any `#[allow]` / `#[deny]` attributes placed 'closer' to the macro (e.g. on an enclosing block or statement) will have no effect. This commit computes a better `lint_node_id` in `InvocationCollector`. When we visit/flat_map an AST node, we assign it a `NodeId` (earlier than we normally would), and store than `NodeId` in current `ExpansionData`. When we collect a macro invocation, the current `lint_node_id` gets cloned along with our `ExpansionData`, allowing it to be used if we need to emit a lint later on. This improves the handling of `#[allow]` / `#[deny]` for `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` and some `asm!`-related lints. The 'legacy derive helpers' lint retains its current behavior (I've inlined the now-removed `lint_node_id` function), since there isn't an `ExpansionData` readily available.
2021-07-17Use LocalExpnId where possible.Camille GILLOT-16/+24
2021-07-13expand: Support helper attributes for built-in derive macrosVadim Petrochenkov-2/+92
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-13 05:53:05 +0000