Fix linting when trailing macro expands to a trailing semi #88996
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
|
(rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ |
|
📌 Commit bd4c967 has been approved by |
bors
added
S-waiting-on-bors
Mark-Simulacrum
added
the
beta-nominated
|
beta-nominating this PR, as it's fixing #87757, which is a beta regression (1.56). |
JohnTitor
added a commit
to JohnTitor/rust
that referenced
this pull request
Sep 19, 2021
…trochenkov
Fix linting when trailing macro expands to a trailing semi
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.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 19, 2021
Rollup of 10 pull requests Successful merges: - rust-lang#87960 (Suggest replacing an inexisting field for an unmentioned field) - rust-lang#88855 (Allow simd_shuffle to accept vectors of any length) - rust-lang#88966 (Check for shadowing issues involving block labels) - rust-lang#88996 (Fix linting when trailing macro expands to a trailing semi) - rust-lang#89017 (fix potential race in AtomicU64 time monotonizer) - rust-lang#89021 (Add a separate error for `dyn Trait` in `const fn`) - rust-lang#89051 (Add intra-doc links and small changes to `std::os` to be more consistent) - rust-lang#89053 (refactor: VecDeques IntoIter fields to private) - rust-lang#89055 (Suggest better place to add call parentheses for method expressions wrapped in parentheses) - rust-lang#89081 (Fix a typo) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
apiraino
added
the
T-compiler
rustbot
added
the
beta-accepted
ehuss
pushed a commit
to ehuss/rust
that referenced
this pull request
Oct 4, 2021
…trochenkov
Fix linting when trailing macro expands to a trailing semi
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.
Merged
ehuss
removed
the
beta-nominated
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Oct 4, 2021
[beta] Beta rollup * Fix WinUWP std compilation errors due to I/O safety rust-lang#88587 * Disable RemoveZsts in generators to avoid query cycles rust-lang#88979 * Disable the evaluation cache when in intercrate mode rust-lang#88994 * Fix linting when trailing macro expands to a trailing semi rust-lang#88996 * Don't use projection cache or candidate cache in intercrate mode rust-lang#89125 * 2229: Mark insignificant dtor in stdlib rust-lang#89144 * Temporarily rename int_roundings functions to avoid conflicts rust-lang#89184 * [rfc 2229] Drop fully captured upvars in the same order as the regular drop code rust-lang#89208 * Use the correct edition for syntax highlighting doctests rust-lang#89277 * Don't normalize opaque types with escaping late-bound regions rust-lang#89285 * Update Let's Encrypt ROOT CA certificate in dist-(i686|x86_64)-linux docker images rust-lang#89486 Cargo update: * - [beta] 1.56 backports (rust-lang/cargo#9958) * - [beta] Revert "When a dependency does not have a version, git or path… (rust-lang/cargo#9912) * - [beta] Fix rustc --profile=dev unstable check. (rust-lang/cargo#9901)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When a macro is used in the trailing expression position of a block
(e.g.
fn foo() { my_macro!() }), we currently parse it as anexpression, rather than a statement. As a result, we ended up
using the
NodeIdof the containing statement as ourlint_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
NodeIdof the expression to emita lint.
Ths commit makes us skip updating
lint_node_idwhen handlinga macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.