-
Notifications
You must be signed in to change notification settings - Fork 13k
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
Change clippy's symbol interning strategy to be reentrant #60907
Conversation
|
This comment has been minimized.
This comment has been minimized.
r? @Zoxc |
} | ||
} | ||
} | ||
|
||
pub fn with_globals<F, R>(f: F) -> R | ||
pub fn with_globals<F, R>(driver_symbols: &[&str], f: F) -> R |
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.
with_globals
could probably keep its interface and delegate to a new with_globals_xxx
function taking &[&str]
.
Too bad Rust still doesn't have default fn parameters to write fn foo(driver_symbols: &[&str] = &[])
.
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.
I was considering that, but it seemed too error prone (since it's too easy to forget to do somewhere).
driver_symbols: &[&str], | ||
cfgspecs: Vec<String>, | ||
) -> FxHashSet<(String, Option<String>)> { | ||
syntax::with_globals(driver_symbols, move || { |
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.
I'm not sure this one needs the extra symbols.
It's a "leaf" function that shouldn't delegate to any tool-specific functionality.
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.
It should not need any symbols at all I believe. Would you mind if I did that change in a separate PR?
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.
It needs symbols because it parses paths and therefore needs to use at least self
/super
/etc.
I guess it's ok to leave this as is because I'm not entirely sure that parsing cannot be intercepted by a tool now or in the future.
This comment has been minimized.
This comment has been minimized.
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
Looks okay, not happy that this affects the signature everywhere, but oh well can't have everything. I think we should land this ASAP even if we have follow-up questions.
It seems like a really bad and ugly idea to have 2 lists of initial symbols. Why does clippy need this? |
We do lots of symbol lookups, e.g. checking paths. |
I have some changes planned that will drastically reduce the number of these that Clippy needs, by virtue of a dedicated diagnostic item registry in rustc (like lang items but weaker), but we'll still need some of these. Though once clippy is only using a small number of these we can reevaluate how these get stored in rustc. Right now we need this to fix RLS for the beta. |
The largest mistake here was doing rust-lang/rust-clippy@b2dbda4 in a same PR with rust version update, especially before beta. With rustc interfaces changing from |
Why not use a lazy_static to initialize clippy specific symbols or use a struct with symbols in clippy's global state? |
That's what we did, it's unsound in multithreaded environments like RLS. (Rust's Symbol API is unsound, that is, Clippy didn't use unsafe code here) |
Yea, I thought I was being smart. I can definitely just fix clippy by essentially reverting all that and using |
If clippy doesn't currently have a way to store global state, I'd rather either 1) use |
I strongly feel that we should land this first since everything is ready to go for the beta. The diagnostic item registry will fix most of the symbols we need, and we can build a good focused system for the rest. |
(If this ends up as a temporary solution for beta only, then could you please implement https://github.com/rust-lang/rust/pull/60907/files#r285057461 and squash to reduce the churn.) |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
☔ The latest upstream changes (presumably #60940) made this pull request unmergeable. Please resolve the merge conflicts. |
I changed clippy to use just-in-time-interning |
and thus fix rls
fixes #60893
fixes #60768
r? @Manishearth @nnethercote