assert! in edition 2018 has a non-hygienic use of panic! #56389
Comments
Nemo157
changed the title
|
This isn't a problem with Also, using |
|
|
|
+1
Probably not (modulo |
That's surprising, it appears to work in edition 2018 with |
|
Well, standard library is still built with Rust 2015, and on 2015 macros from |
|
#58702 appears to have extended the non-hygienity to other > # d6f513ec7d1e83c8689f94fb48686dd11f1d1c80 is just before #58702
> echo '#![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }' | rustc +d6f513ec7d1e83c8689f94fb48686dd11f1d1c80 --edition 2018 -
> echo '#![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }' | rustc +d6f513ec7d1e83c8689f94fb48686dd11f1d1c80 --edition 2015 -
> # 5d20ff4d2718c820632b38c1e49d4de648a9810b is the merge of #58702
> echo '#![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }' | rustc +5d20ff4d2718c820632b38c1e49d4de648a9810b --edition 2015 -
error: cannot find macro `panic!` in this scope
--> <anon>:1:37
|
1 | #![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: have you added the `#[macro_use]` on the module/import?
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error: aborting due to previous error
> echo '#![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }' | rustc +5d20ff4d2718c820632b38c1e49d4de648a9810b --edition 2018 -
error: cannot find macro `panic!` in this scope
--> <anon>:1:37
|
1 | #![no_implicit_prelude] fn main() { ::std::assert_eq!(1, 1) }
| ^^^^^^^^^^^^^^^^^^^^^^^
|
= help: have you added the `#[macro_use]` on the module/import?
= note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
error: aborting due to previous error |
|
The non-hygienity even extends to the |
Hygienize macros in the standard library Same as rust-lang#55597, but for all macros in the standard library. Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site. Technically this is a breaking change, so crater run would probably be useful. --- One exception that is not hygienized is calls to `panic!(...)`. Macros defined in libcore do not want to call `core::panic`. What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings. EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done). Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code. The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic. Then standard library macros could delegate to this built-in macro. The macro could be named `panic` too, that would fix rust-lang#61567. (This PR doesn't do that.) --- cc rust-lang#56389 cc rust-lang#61567 Fixes rust-lang#61699 r? @alexcrichton
Hygienize macros in the standard library Same as rust-lang#55597, but for all macros in the standard library. Nested macro calls will now call what they are intended to call rather than whatever is in the closest scope at call site. Technically this is a breaking change, so crater run would probably be useful. --- One exception that is not hygienized is calls to `panic!(...)`. Macros defined in libcore do not want to call `core::panic`. What they really want to call is either `std::panic` or `core::panic` depending on `no_std` settings. EDIT: After some thought, recursive calls to `panic` from `panic` itself probably do want to use `$crate` (UPDATE: done). Calling `std::panic` from macros defined in std and "whatever `panic` is in scope" from macros defined in libcore is probably even worse than always calling "whatever `panic` is in scope", so I kept the existing code. The only way to do the std/core switch correctly that I'm aware of is to define a built-in panic macro that would dispatch to `std::panic` or `core::panic` using compiler magic. Then standard library macros could delegate to this built-in macro. The macro could be named `panic` too, that would fix rust-lang#61567. (This PR doesn't do that.) --- cc rust-lang#56389 cc rust-lang#61567 Fixes rust-lang#61699 r? @alexcrichton
|
I'm going to close this in favor of #61567 (which doesn't have a discussion distracting from the primary issue). |
This code runs fine on edition 2015, and has no warnings with
#![warn(rust_2018_compatibility)], but fails to compile on edition 2018 (playground):error message:
The text was updated successfully, but these errors were encountered: