Introduced DynEq + DynHash bounds for MacroPlugin, InlineMacroExprPlugin and AnalyzerPlugin traits

[integraledelebesgue]

Stack:

• Migrated the compiler to per-crate plugin queries #6843
• Removed shared databases from tests #6842
• Redesigned semantic testing utilities #6841
• Introduced queries for crate plugins in DefsGroup and SemanticGroup #6840
• Introduced DynEq + DynHash bounds for MacroPlugin, InlineMacroExprPlugin and AnalyzerPlugin traits #6839 ⬅
• Delegated PluginSuite initialization outside RootDatabaseBuilder #6838

⚠️ 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 

[orizi]

Reviewed 31 of 31 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @integraledelebesgue)

---

-- commits line 2 at r1:
please elaborate as to why you need this.

[mkaput]

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

---

-- commits line 2 at r1:

Previously, orizi wrote…

please elaborate as to why you need this.

I don't think we want to go this route. Have you considered just hashing and comparing pointers that are underlying to Arc<MacroPlugin> at all?

[integraledelebesgue]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Draggu)

---

-- commits line 2 at r1:

Previously, mkaput (Marek Kaput) wrote…

I don't think we want to go this route. Have you considered just hashing and comparing pointers that are underlying to Arc<MacroPlugin> at all?

That was my first idea :) Such an approach is fine for plugins being unit structs, but is it safe to generalize it for non-unit plugins, especially the Scarb plugin? cc: @Draggu

[mkaput]

Reviewed 31 of 31 files at r1, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Draggu)

---

-- commits line 2 at r1:

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

That was my first idea :) Such an approach is fine for plugins being unit structs, but is it safe to generalize it for non-unit plugins, especially the Scarb plugin? cc: @Draggu

wdym by Scarb plugin?

no plugin known to me has any state (and having one is pretty hardcore idea) so we can afford having duplicate instances of a plugin in worst case

[integraledelebesgue]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Draggu)

---

-- commits line 2 at r1:

Previously, mkaput (Marek Kaput) wrote…

wdym by Scarb plugin?

no plugin known to me has any state (and having one is pretty hardcore idea) so we can afford having duplicate instances of a plugin in worst case

I'm talking about plugins like, for example, ProcMacroHostPlugin from Scarb. It's not a unit struct. At the same time, it becomes a part of a plugin suite loaded into a RootDatabase during Scarb compilation here.

[integraledelebesgue]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Draggu)

---

-- commits line 2 at r1:

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

I'm talking about plugins like, for example, ProcMacroHostPlugin from Scarb. It's not a unit struct. At the same time, it becomes a part of a plugin suite loaded into a RootDatabase during Scarb compilation here.

I'm not saying we cannot compare pointers here, just wonder if that's a good approach for all possible forms of plugins.

[mkaput]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @Draggu)

---

-- commits line 2 at r1:

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

I'm not saying we cannot compare pointers here, just wonder if that's a good approach for all possible forms of plugins.

discussed offline -> let's go with pointer comparisons

[integraledelebesgue]

Closing pull request: commit has gone away