-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Rust: extract generic parameters, arguments and resolve bound type variables #19237
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
Conversation
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.
Pull Request Overview
This PR aims to support the extraction of generic parameters, arguments, and the resolution of bound type variables in Rust. It introduces two new generic structs (LocalKey and Thing) and implements a From trait conversion for Thing instantiated with type X.
Files not reviewed (3)
- rust/ql/lib/codeql/rust/elements/internal/LifetimeImpl.qll: Language not supported
- rust/ql/test/extractor-tests/crate_graph/modules.expected: Language not supported
- rust/ql/test/extractor-tests/crate_graph/modules.ql: Language not supported
Comments suppressed due to low confidence (2)
rust/ql/test/extractor-tests/crate_graph/module.rs:47
- [nitpick] The struct name 'LocalKey' is ambiguous; consider renaming it or adding a doc comment to clarify its purpose.
pub struct LocalKey<T: 'static> {
rust/ql/test/extractor-tests/crate_graph/module.rs:48
- [nitpick] Consider renaming the field 'inner' to a more descriptive name that reflects its functionality to improve code readability.
inner: fn(Option<&mut Option<T>>) -> *const T,
5c67429
to
df5f003
Compare
rust/ql/test/library-tests/path-resolution/path-resolution.expected
Outdated
Show resolved
Hide resolved
a2844cc
to
77d8ae8
Compare
This reverts commit 260322b.
Enum variants cannot be declared as a module item, they can only be imported
77d8ae8
to
7bfd5f1
Compare
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'll dive into it more in depth tomorrow, but a generic comment I have is that crate_graph.rs
is growing even more in complexity, and as far as I can tell it's really using very unstable parts of rust-analyzer. In my rust-analyzer updates experiences, this is the code that has been breaking on every update and needs quite some effort to keep up to date (see the next update in the queue).
That said, is that something we can conceivably avoid? Is running some limited form of the regular generated extractor on dependency source out of the question because of performance? I'm starting to fear this code is creeping out of control a bit, and risks becoming the biggest maintenance burden of the whole extractor.
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.
Hoestly did not have a deep look at the new crate graph code, but we can work on that in the next days.
This PR aims to support the extraction of generic parameters, arguments, and the resolution of bound type variables in Rust.