about summary refs log tree commit diff
path: root/compiler/rustc_expand/src/expand.rs
AgeCommit message (Collapse)AuthorLines
2021-09-28Improve help for recursion limit errorsRoss MacArthur-2/+6
2021-09-15Fix linting when trailing macro expands to a trailing semiAaron Hill-6/+9
When a macro is used in the trailing expression position of a block (e.g. `fn foo() { my_macro!() }`), we currently parse it as an expression, rather than a statement. As a result, we ended up using the `NodeId` of the containing statement as our `lint_node_id`, even though we don't normally do this for macro calls. If such a macro expands to an expression with a `#[cfg]` attribute, then the trailing statement can get removed entirely. This lead to an ICE, since we were usng the `NodeId` of the expression to emit a lint. Ths commit makes us skip updating `lint_node_id` when handling a macro in trailing expression position. This will cause us to lint at the closest parent of the macro call.
2021-09-10Record call_site parent for macros.Camille GILLOT-1/+14
2021-09-02expand: Treat more macro calls as statement macro callsVadim Petrochenkov-33/+67
2021-08-21Remove `NonMacroAttr.mark_used`Aaron Hill-1/+1
2021-08-21Remove `Session.used_attrs` and move logic to `CheckAttrVisitor`Aaron Hill-4/+1
Instead of updating global state to mark attributes as used, we now explicitly emit a warning when an attribute is used in an unsupported position. As a side effect, we are to emit more detailed warning messages (instead of just a generic "unused" message). `Session.check_name` is removed, since its only purpose was to mark the attribute as used. All of the callers are modified to use `Attribute.has_name` Additionally, `AttributeType::AssumedUsed` is removed - an 'assumed used' attribute is implemented by simply not performing any checks in `CheckAttrVisitor` for a particular attribute. We no longer emit unused attribute warnings for the `#[rustc_dummy]` attribute - it's an internal attribute used for tests, so it doesn't mark sense to treat it as 'unused'. With this commit, a large source of global untracked state is removed.
2021-08-12Revert "Rollup merge of #87779 - Aaron1011:stmt-ast-id, r=petrochenkov"Aaron Hill-2/+7
Fixes #87877 This change interacts badly with `noop_flat_map_stmt`, which synthesizes multiple statements with the same `NodeId`. I'm working on a better fix that will still allow us to remove this special case. For now, let's revert the change to fix the ICE. This reverts commit a4262cc9841d91d48ef994b36eab323e615a7083, reversing changes made to 8ee962f88e1be7e29482b13c7776c26b98a93bf7.
2021-08-06Remove special case for statement `NodeId` assignmentAaron Hill-7/+2
We now let `noop_flat_map_stmt` assign `NodeId`s (via `visit_id`), just as we do for other AST nodes.
2021-07-25Auto merge of #87381 - Aaron1011:note-semi-trailing-macro, r=petrochenkovbors-2/+18
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-24Rollup merge of #87389 - Aaron1011:expand-known-attrs, r=wesleywiserManish Goregaokar-2/+2
Rename `known_attrs` to `expanded_inert_attrs` and move to rustc_expand There's no need for this to be (untracked) global state.
2021-07-24Display an extra note for trailing semicolon lint with trailing macroAaron Hill-2/+18
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-2/+2
There's no need for this to be (untracked) global state.
2021-07-19Warn on inert attributes used on bang macro invocationAaron Hill-16/+33
These attributes are currently discarded. This may change in the future (see #63221), but for now, placing inert attributes on a macro invocation does nothing, so we should warn users about it. Technically, it's possible for there to be attribute macro on the same macro invocation (or at a higher scope), which inspects the inert attribute. For example: ```rust #[look_for_inline_attr] #[inline] my_macro!() #[look_for_nested_inline] mod foo { #[inline] my_macro!() } ``` However, this would be a very strange thing to do. Anyone running into this can manually suppress the warning.
2021-07-17Only use `assign_id!` for ast nodes that support attributesAaron Hill-5/+5
2021-07-17Add additional missing lint handling logicAaron Hill-1/+8
2021-07-17Compute a better `lint_node_id` during expansionAaron Hill-22/+78
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-3/+3
2021-07-14Auto merge of #87118 - JohnTitor:rollup-8ltidsq, r=JohnTitorbors-4/+8
Rollup of 6 pull requests Successful merges: - #87085 (Search result colors) - #87090 (Make BTreeSet::split_off name elements like other set methods do) - #87098 (Unignore some pretty printing tests) - #87099 (Upgrade `cc` crate to 1.0.69) - #87101 (Suggest a path separator if a stray colon is found in a match arm) - #87102 (Add GUI test for "go to first" feature) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
2021-07-14Suggest a path separator if a stray colon is found in a match armFabian Wolff-4/+8
Co-authored-by: Esteban Kuber <estebank@users.noreply.github.com>
2021-07-13Cache expansion hash.Camille GILLOT-2/+2
2021-06-21Rollup merge of #86491 - petrochenkov:derefact, r=Aaron1011Yuki Okushi-28/+2
expand: Move some more derive logic to rustc_builtin_macros And cleanup some `unwrap`s in `cfg_eval`. Refactorings extracted from https://github.com/rust-lang/rust/pull/83354 and https://github.com/rust-lang/rust/pull/86057. r? ``@Aaron1011``
2021-06-21Do not set depth to 0 in fully_expand_fragmentDeadbeef-1/+1
2021-06-20expand: Move some more derive logic to `rustc_builtin_macros`Vadim Petrochenkov-28/+2
2021-06-04Remove `doc(include)`Joshua Nelson-139/+5
2021-05-05Use local and remapped paths where appropriateAndy Wang-1/+1
2021-05-05Make local_path in RealFileName::Remapped Option to be removed in exported ↵Andy Wang-1/+3
metadata
2021-05-05Rename RealFileName::Named to LocalPath and Devirtualized to RemappedAndy Wang-1/+1
2021-04-29Implement RFC 1260 with feature_name `imported_main`.Charles Lew-1/+3
2021-04-11Implement token-based handling of attributes during expansionAaron Hill-10/+28
This PR modifies the macro expansion infrastructure to handle attributes in a fully token-based manner. As a result: * Derives macros no longer lose spans when their input is modified by eager cfg-expansion. This is accomplished by performing eager cfg-expansion on the token stream that we pass to the derive proc-macro * Inner attributes now preserve spans in all cases, including when we have multiple inner attributes in a row. This is accomplished through the following changes: * New structs `AttrAnnotatedTokenStream` and `AttrAnnotatedTokenTree` are introduced. These are very similar to a normal `TokenTree`, but they also track the position of attributes and attribute targets within the stream. They are built when we collect tokens during parsing. An `AttrAnnotatedTokenStream` is converted to a regular `TokenStream` when we invoke a macro. * Token capturing and `LazyTokenStream` are modified to work with `AttrAnnotatedTokenStream`. A new `ReplaceRange` type is introduced, which is created during the parsing of a nested AST node to make the 'outer' AST node aware of the attributes and attribute target stored deeper in the token stream. * When we need to perform eager cfg-expansion (either due to `#[derive]` or `#[cfg_eval]`), we tokenize and reparse our target, capturing additional information about the locations of `#[cfg]` and `#[cfg_attr]` attributes at any depth within the target. This is a performance optimization, allowing us to perform less work in the typical case where captured tokens never have eager cfg-expansion run.
2021-04-10Expand derive invocations in left-to-right orderAaron Hill-3/+9
While derives were being collected in left-to-order order, the corresponding `Invocation`s were being pushed in the wrong order.
2021-04-07Rollup merge of #83816 - JohnTitor:unused-doc-comments-on-macros, r=varkorDylan DPC-2/+12
Trigger `unused_doc_comments` on macros at once Fixes #83768
2021-04-06Rollup merge of #83814 - petrochenkov:emptyexpr, r=davidtwcoYuki Okushi-1/+8
expand: Do not ICE when a legacy AST-based macro attribute produces and empty expression Fixes https://github.com/rust-lang/rust/issues/80251 The reported error is the same as for `let _ = #[cfg(FALSE)] EXPR;`
2021-04-04resolve/expand: Cache intermediate results of `#[derive]` expansionVadim Petrochenkov-1/+1
2021-04-04Trigger `unused_doc_comments` on macros at onceYuki Okushi-2/+12
2021-04-03expand: Do not ICE when a legacy AST-based macro attribute produces and ↵Vadim Petrochenkov-1/+8
empty expression
2021-03-25Ban custom inner attributes in expressions and statementsAaron Hill-7/+13
2021-03-19stabilize or_patternsmark-2/+2
2021-03-16ast/hir: Rename field-related structuresVadim Petrochenkov-30/+30
StructField -> FieldDef ("field definition") Field -> ExprField ("expression field", not "field expression") FieldPat -> PatField ("pattern field", not "field pattern") Also rename visiting and other methods working on them.
2021-03-14expand: Resolve and expand inner attributes on out-of-line modulesVadim Petrochenkov-7/+13
2021-03-05expand: Align some code with the PR fixing inner attributes on out-of-line ↵Vadim Petrochenkov-6/+13
modules
2021-03-05rustc_interface: Hide some hacky details of early linting from expandVadim Petrochenkov-6/+4
2021-03-05expand: Some more consistent naming in module loadingVadim Petrochenkov-9/+11
2021-03-05expand: Less path cloning during module loadingVadim Petrochenkov-14/+22
2021-03-05expand: Move module file path stack from global session to expansion dataVadim Petrochenkov-35/+36
Also don't push the paths on the stack directly in `fn parse_external_mod`, return them instead.
2021-02-27Combine HasAttrs and HasTokens into AstLikeAaron Hill-4/+4
When token-based attribute handling is implemeneted in #80689, we will need to access tokens from `HasAttrs` (to perform cfg-stripping), and we will to access attributes from `HasTokens` (to construct a `PreexpTokenStream`). This PR merges the `HasAttrs` and `HasTokens` traits into a new `AstLike` trait. The previous `HasAttrs` impls from `Vec<Attribute>` and `AttrVec` are removed - they aren't attribute targets, so the impls never really made sense.
2021-02-23expand: Preserve order of inert attributes during expansionVadim Petrochenkov-9/+14
2021-02-18ast: Keep expansion status for out-of-line module itemsVadim Petrochenkov-43/+47
Also remove `ast::Mod` which is mostly redundant now
2021-02-18ast: Stop using `Mod` in `Crate`Vadim Petrochenkov-24/+14
Crate root is sufficiently different from `mod` items, at least at syntactic level. Also remove customization point for "`mod` item or crate root" from AST visitors.
2021-02-17Rollup merge of #81869 - mark-i-m:leading-vert, r=petrochenkovDylan DPC-2/+4
Simplify pattern grammar, improve or-pattern diagnostics This implements the change under FCP in https://github.com/rust-lang/rust/issues/81415. It allows nested or-patterns to contain a leading `|`, simplifying the [grammar for patterns](https://github.com/rust-lang/reference/pull/957/files?short_path=cc629f1#diff-cc629f15712821139bc706c63b3845ab59a008e2a998e08ffad42e3aebcbcbe2). Along the way, we also improve the diagnostics around a few specially-handled cases, such as using `||` instead of `|`, using or-patterns in fn params, including the leading `|` in the pattern span, etc. r? `@petrochenkov`
2021-02-15Simplify pattern grammar by allowing nested leading vertmark-2/+4
Along the way, we also implement a handful of diagnostics improvements and fixes, particularly with respect to the special handling of `||` in place of `|` and when there are leading verts in function params, which don't allow top-level or-patterns anyway.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 07:18:43 +0000