-
Notifications
You must be signed in to change notification settings - Fork 0
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
Store plugins in the Crate structure #209
base: spr/main/fa144cb1
Are you sure you want to change the base?
Conversation
eb2d8ce
to
659c827
Compare
5a57025
to
9942c29
Compare
659c827
to
a1a6506
Compare
b7e504f
to
456121c
Compare
639396f
to
98cc352
Compare
456121c
to
29698c0
Compare
98cc352
to
321bd50
Compare
29698c0
to
ff0fc4d
Compare
321bd50
to
c43464a
Compare
ff0fc4d
to
8364856
Compare
c43464a
to
c161fce
Compare
67150c9
to
2a85ae2
Compare
use cairo_lang_utils::{Intern, LookupIntern}; | ||
use smol_str::SmolStr; | ||
|
||
use crate::lang::db::AnalysisDatabase; | ||
|
||
/// A complete set of information needed to set up a real crate in the analysis database. | ||
#[derive(Debug, PartialEq, Eq)] | ||
#[derive(Debug)] |
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 would like to preserve the plain nature of this struct. I know we're not based on upstream changes to the compiler yet here, but do you think if it would be possible to keep just a set of plugin ids here?
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.
You don't have plugin ids in this PR at all since they are never interned, only treated as an input
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.
Storing IDs in Crate
seems possible when we start using the new compiler API, but it would require passing a database to extract_crates
, which can be tricky
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.
@piotmag769 is right. we would need to have a custom ID mechanism (PackageIDs I guess) at this stage. nonetheless, this is a separate piece of work which is not needed urgently right now
48c6c86
to
c90354f
Compare
575ba49
to
703c3ee
Compare
c90354f
to
30755d0
Compare
30755d0
to
9bc35f1
Compare
703c3ee
to
4ab2c0a
Compare
commit-id:988401af
4ab2c0a
to
8eeba76
Compare
Some(builtin_plugin.suite()) | ||
}) | ||
.fold( | ||
get_default_plugin_suite(), // All crates have basic plugins set by default. |
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.
You need to add tricks here too :c
|
||
/// Built-in plugins required by the crate. | ||
#[allow(dead_code)] // TODO: remove. The field is used later in the stack | ||
pub builtin_plugins: PluginSuite, |
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.
We probably want to expose them in ViewAnalyzedCrates
(the names of builtin plugins that were loaded), wdyt?
Stack: