feat(mlir): plumb cross-contract dependencies through the MLIR pipeline

[hedgar2017]

With per-contract MLIR emission, the linker assembles bytecodes across contracts but only sees the dependencies declared on each EVMContractObject. The MLIR branch in solx-core/src/project/contract/mod.rs was constructing those with only the contract's own runtime identifier, so new B() from contract A could not resolve B's deploy bytecode at link time — the LLD pass produced non-ref undefined symbol: __datasize__$<hash>$__.

The Yul pipeline solves the same problem by walking each Yul object's body for datasize/dataoffset literal-string arguments and pushing them into a solx_codegen_evm::Dependencies struct that the assembler later consumes (solx-yul/src/parser/statement/expression/function_call/mod.rs:112-135). This change mirrors that pattern for the MLIR side: MlirOutput carries a Vec<String> of cross-contract references, solx_mlir::Context accumulates names via add_dependency (interior mut, since emitters hold &Context), and solx-core's ContractMLIR propagates them into the Dependencies struct fed to the assembler.

Dormant in this PR — no emitter calls Context::add_dependency yet, so the list is always empty and the link behavior is unchanged. tests/solidity/simple -O M3B3 produces 1896 passed / 3 failed / 307 invalid both with and without this change. The follow-up PR that lowers new B() to sol.new will start populating the list; from that point the assembler will resolve cross-contract deploy-code references the same way it already does for the Yul pipeline.

[Copilot]

Pull request overview

This PR extends the MLIR (Slang→MLIR) pipeline to carry cross-contract dependency information through to the solx-codegen-evm assembler/linker dependency mechanism, matching the existing behavior/pattern used by the Yul pipeline. Although the dependency list is currently not populated by any emitter, the plumbing is added end-to-end so future emitters can record cross-contract references (e.g., sol.new) for correct link-time resolution.

Changes:

• Add a dependencies: Vec<String> field to solx-mlir::MlirOutput and to solx-core’s MLIR IR representation so it can be serialized/deserialized and propagated.
• Add dependency collection to solx_mlir::Context via interior mutability (add_dependency) and drain it into MlirOutput at finalize_module.
• Thread MLIR dependencies into solx_codegen_evm::Dependencies construction in the MLIR compilation path in solx-core.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
solx-mlir/src/output.rs	Adds serialized dependencies field to MLIR pipeline output.
solx-mlir/src/context/mod.rs	Introduces dependency accumulation (RefCell<Vec<String>>), add_dependency, and drains into MlirOutput in finalize_module.
solx-core/src/project/mod.rs	Propagates MlirOutput.dependencies into ContractMLIR for deploy/runtime segments.
solx-core/src/project/contract/mod.rs	Pushes MLIR cross-contract dependencies into solx_codegen_evm::Dependencies for MLIR objects during object construction.
solx-core/src/project/contract/ir/mlir.rs	Adds dependencies field to the internal MLIR IR struct used by solx-core.

[abinavpp]

how exactly will we track the dependencies? every time we visit the new, creationCode, runtimeCode? I think it'll be better to combine supports for them here so that we can review how this change will enable those lowering.