Migrated the compiler to per-crate plugin queries

[integraledelebesgue]

Stack:

• Migrated the compiler to per-crate plugin queries #6843 ⬅
• Introduced default plugin suites to the RootDatabaseBuilder #6852
• Introduced queries for crate plugins in DefsGroup and SemanticGroup #6840

⚠️ Part of a stack created by spr. Do not merge manually using the UI - doing so may have unexpected results.

[reviewable-StarkWare]

This change is 

[integraledelebesgue]

Reviewable status: 0 of 65 files reviewed, 1 unresolved discussion (waiting on @mkaput, @orizi, and @piotmag769)

---

a discussion (no related file):
I have two problems here which I am work on now:

1. Fallback from "override" to "default" input (e.g. DefsGroup::default_macro_plugins and DefsGroup::override_crate_macro_plugins) is tricky to implement due to the way the input getters are implemented in Salsa: they panic. Sadly, I cannot catch the panic without constraining the DefsGroup (and, consequently, all its subtraits) to UnwindSafe.
2. Tests related to circuits break because the compiler's input has Tuple<...> types instead of (...) structural types.

However, the rest of the stack is ready to be reviewed.

[mkaput]

Reviewed 58 of 64 files at r3, all commit messages.
Reviewable status: 58 of 65 files reviewed, 1 unresolved discussion (waiting on @integraledelebesgue, @orizi, and @piotmag769)

---

a discussion (no related file):

Previously, integraledelebesgue (Jan Smółka) wrote…

I have two problems here which I am work on now:

1. Fallback from "override" to "default" input (e.g. DefsGroup::default_macro_plugins and DefsGroup::override_crate_macro_plugins) is tricky to implement due to the way the input getters are implemented in Salsa: they panic. Sadly, I cannot catch the panic without constraining the DefsGroup (and, consequently, all its subtraits) to UnwindSafe.
2. Tests related to circuits break because the compiler's input has Tuple<...> types instead of (...) structural types.

However, the rest of the stack is ready to be reviewed.

Ad 1. I believe that's the reason file_overrides in FilesGroup are implemented as two queries: one, the parameterless input, keeps an HashMap of FileId -> override and the other query meant for broad use does the lookup and returns Option

[mkaput]

Reviewed 1 of 65 files at r1, 6 of 64 files at r3.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @integraledelebesgue, @orizi, and @piotmag769)

---

crates/cairo-lang-semantic/src/types.rs line 187 at r3 (raw file):

    /// containing it.
    pub fn is_phantom(&self, db: &dyn SemanticGroup) -> bool {
        let Some(module_file_id) = self.module_file_id(db) else {

I think this generalization of module_file_id for any TypeId is misleading a bit, and not really that useful outside this context. See my other comment down this file for an explanation of how I believe this should work.

---

crates/cairo-lang-semantic/src/types.rs line 205 at r3 (raw file):

                    .iter()
                    .any(|attr| id.has_attr(db, attr).unwrap_or_default()),
            },

I think this is the place where you should actually look for the crate and its declared phantom type attrs. Here, you know a concrete item that we're interested in, so we can always reliably ask for its crate.

Code quote:

            TypeLongId::Concrete(id) => match id {
                ConcreteTypeId::Struct(id) => phantom_type_attributes
                    .iter()
                    .any(|attr| id.has_attr(db, attr).unwrap_or_default()),
                ConcreteTypeId::Enum(id) => phantom_type_attributes
                    .iter()
                    .any(|attr| id.has_attr(db, attr).unwrap_or_default()),
                ConcreteTypeId::Extern(id) => phantom_type_attributes
                    .iter()
                    .any(|attr| id.has_attr(db, attr).unwrap_or_default()),
            },

---

crates/cairo-lang-semantic/src/types.rs line 208 at r3 (raw file):

            TypeLongId::Tuple(inner) => inner.iter().any(|ty| ty.is_phantom(db)),
            TypeLongId::FixedSizeArray { type_id, .. } => type_id.is_phantom(db),
            TypeLongId::Snapshot(_)

This is an example where generalized module_file_id might not be a good idea: we don't need it for snapshots, yet your code attempted to look for something.

[Draggu]

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @integraledelebesgue, @orizi, and @piotmag769)

[mkaput]

Reviewed 3 of 3 files at r4, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @integraledelebesgue, @orizi, and @piotmag769)

[integraledelebesgue]

Reviewable status: 57 of 65 files reviewed, 2 unresolved discussions (waiting on @mkaput, @orizi, and @piotmag769)

---

crates/cairo-lang-semantic/src/types.rs line 205 at r3 (raw file):

Previously, mkaput (Marek Kaput) wrote…

I think this is the place where you should actually look for the crate and its declared phantom type attrs. Here, you know a concrete item that we're interested in, so we can always reliably ask for its crate.

Done, as you said :)

[integraledelebesgue]

Reviewable status: 57 of 65 files reviewed, 2 unresolved discussions (waiting on @mkaput, @orizi, and @piotmag769)

---

a discussion (no related file):

Previously, mkaput (Marek Kaput) wrote…

Ad 1. I believe that's the reason file_overrides in FilesGroup are implemented as two queries: one, the parameterless input, keeps an HashMap of FileId -> override and the other query meant for broad use does the lookup and returns Option

Update: 2 has been fixed, now I work on 1

[mkaput]

Reviewed 8 of 8 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @orizi and @piotmag769)

[mkaput]

Reviewed 9 of 9 files at r6, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @integraledelebesgue, @orizi, and @piotmag769)

---

crates/cairo-lang-compiler/src/db.rs line 57 at r6 (raw file):

        init_lowering_group(&mut res, inlining_strategy);
        init_defs_group(&mut res);
        init_semantic_group(&mut res);

this should be changed in the PR introducing these fns

[integraledelebesgue]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @mkaput, @orizi, and @piotmag769)

---

crates/cairo-lang-compiler/src/db.rs line 57 at r6 (raw file):

Previously, mkaput (Marek Kaput) wrote…

this should be changed in the PR introducing these fns

I know it might not be very review-friendly, but this PR, in general, introduces all the new logic I prepared in the preceding ones. Thus I decided to use these functions here too

[mkaput]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @orizi and @piotmag769)

---

crates/cairo-lang-compiler/src/db.rs line 57 at r6 (raw file):

Previously, integraledelebesgue (Jan Smółka) wrote…

I know it might not be very review-friendly, but this PR, in general, introduces all the new logic I prepared in the preceding ones. Thus I decided to use these functions here too

mind that #6840 is potentially broken without changes from this PR, that's what I'm mostly nitpicking about. but yeah, this is nitpicking on my side.

unlocking

[mkaput]

Reviewed 6 of 6 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @orizi and @piotmag769)

[orizi]

Reviewed 52 of 64 files at r3, 4 of 8 files at r5, 3 of 9 files at r6, 6 of 6 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @piotmag769)

[piotmag769]

Really good job (reviewed everything as full diff of the 3 PRs, everything seems fine)

Reviewed 52 of 64 files at r3, 5 of 8 files at r5, 3 of 9 files at r6, 6 of 6 files at r7, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @integraledelebesgue)