rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
359bfa901b9d8eddbed7b88b6716dbb77b7bfb95
rust/tests/ui/macros/lint-trailing-macro-call.stderr

36 lines
1.9 KiB
Plaintext
Raw Normal View History

Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
2025-07-23 09:14:12 -07:00
error: trailing semicolon in macro used in expression position
--> $DIR/lint-trailing-macro-call.rs:7:25
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.
2021-09-15 19:32:03 -05:00
|
Use `cfg(false)` in UI tests
2025-03-29 17:24:03 +00:00
LL | #[cfg(false)] 25;
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.
2021-09-15 19:32:03 -05:00
| ^
...
LL | expand_it!()
| ------------ in this macro invocation
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
= note: macro invocations at the end of a block are treated as expressions
= note: to ignore the value produced by the macro, add a semicolon after the invocation of `expand_it`
bless tests with new lint messages
2025-04-28 13:47:25 +02:00
= note: `#[deny(semicolon_in_expressions_from_macros)]` (part of `#[deny(future_incompatible)]`) on by default
Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
2025-07-23 09:14:12 -07:00
= note: this error originates in the macro `expand_it` (in Nightly builds, run with -Z macro-backtrace for more info)
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.
2021-09-15 19:32:03 -05:00
Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
2025-07-23 09:14:12 -07:00
error: aborting due to 1 previous error
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.
2021-09-15 19:32:03 -05:00
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
2022-10-22 17:28:08 -05:00
Future incompatibility report: Future breakage diagnostic:
Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
2025-07-23 09:14:12 -07:00
error: trailing semicolon in macro used in expression position
--> $DIR/lint-trailing-macro-call.rs:7:25
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
2022-10-22 17:28:08 -05:00
|
Use `cfg(false)` in UI tests
2025-03-29 17:24:03 +00:00
LL | #[cfg(false)] 25;
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
2022-10-22 17:28:08 -05:00
| ^
...
LL | expand_it!()
| ------------ in this macro invocation
|
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
= note: macro invocations at the end of a block are treated as expressions
= note: to ignore the value produced by the macro, add a semicolon after the invocation of `expand_it`
bless tests with new lint messages
2025-04-28 13:47:25 +02:00
= note: `#[deny(semicolon_in_expressions_from_macros)]` (part of `#[deny(future_incompatible)]`) on by default
Upgrade semicolon_in_expressions_from_macros from warn to deny This is already warn-by-default, and a future compatibility warning (FCW) that warns in dependencies. Upgrade it to deny-by-default, as the next step towards hard error.
2025-07-23 09:14:12 -07:00
= note: this error originates in the macro `expand_it` (in Nightly builds, run with -Z macro-backtrace for more info)
Add `SEMICOLON_IN_EXPRESSIONS_FROM_MACROS` to future-incompat report
2022-10-22 17:28:08 -05:00
Reference in New Issue Copy Permalink