Yul AST contains dialect

[clonker]

Follow up of #15534.

I streamlined some interfaces which would take an object as well as the dialect to just take the object and instead pull the dialect out of it. I think a lot more could be done potentially by reworking most optimizer steps to optionally run on an instance of yul::AST instead of the root block - that way dialect <-> ast consistency would be harder to break.

[cameel]

I think a lot more could be done potentially by reworking most optimizer steps to optionally run on an instance of yul::AST instead of the root block

One additional place that could benefit from it (and is much less work than the whole optimizer) would be the AsmAnalyzer. I still takes the dialect and the root block separately.

[clonker]

One additional place that could benefit from it (and is much less work than the whole optimizer) would be the AsmAnalyzer. I still takes the dialect and the root block separately.

That requires rethinking the compilability checker / the AST itself a bit, as there the dialect is overridden with the NoOutputDialect decoration when passed into AsmAnalyzer. We could offer three overloads of analyzeStrictAssertCorrect though, with

• AsmAnalysisInfo analyzeStrictAssertCorrect(Object const& _object),
• AsmAnalysisInfo analyzeStrictAssertCorrect(AST const& _ast, Object::Structure _objectStructure), and
• AsmAnalysisInfo analyzeStrictAssertCorrect(Dialect const& _dialect, Block const& _astRoot, Object::Structure _objectStructure).

Then at least where no decorated dialect is required, we can take the AST instance directly.

[cameel]

@clonker Interesting. I wasn't aware of this pattern, but looking it it now, this is a really weird design. Having generateCode() as a part of the dialect seems unnecessary. I think that Dialect was meant to be more of a declarative component so tightly coupling it with code generation now leads to issues like this. Code generation should sit in some other class that we would only use in places where we actually want to generate it - in vast majority of places that use Dialect we don't.

So yeah, a proper solution is more work than just a small refactor. But there is a simple workaround - just pass the original dialect from the object to AsmAnalyzer. AsmAnalyzer is not supposed to call generateCode() anyway so there's no difference in the current usage.

There's already an implicit assumption in CompilabilityChecker that, other than code generation, NoOutputEVMDialect matches all aspects of the dialect present in the object. If it does not, things will break. Passing in the original dialect just means that we'll only see the effects of the breakage during code generation if it ever happens (and it's not supposed to ever happen). Might be worth a comment to document that assumption.