-
Notifications
You must be signed in to change notification settings - Fork 13.4k
resolve: Tweak private_macro_use
lint to be compatible with upcoming macro prelude changes
#141934
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…g macro prelude changes
rustbot has assigned @compiler-errors. Use |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there some way we can test this behavior? Also for posterity could you explain why this blocks that PR you linked in the description?
@compiler-errors I've updated the PR description. |
Thanks. @bors r+ |
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
Unblocks #139493.
Zulip thread requesting help - #t-compiler/help > Help requested for effects of #139493.
This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from #139493 will no longer cause regressions in tests like
tests/ui/imports/issue-119369.rs
ortests/ui/extern/issue-80074.rs
.This is achieved by moving the "is this thing in stdlib prelude" check from an early point (
fn process_macro_use_imports
) to a later point (fn record_use_inner
), at which the stdlib prelude is already populated and can be inspected.(The
is_builtin_macro
check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)