feat(slang): inheritance

[hedgar2017]

Lowers contracts with contract bases in the Slang frontend: inherited state and getters, virtual dispatch to the most-derived override, super and contract-qualified calls, and the base-constructor chain with each argument list evaluated at the call to its target. The tester's Slang view follows the compilation API of the revision this pins.

cargo run-tester-slang: 20182 passed, 85 failed, 35 invalid.

[github-actions]

Coverage Summary

Crate	Line Coverage	Function Coverage
solx	🟢 83.6%	🔴 20.0%
solx-benchmark-converter	🔴 0.0%	🔴 0.0%
solx-codegen-evm	🔴 24.7%	🔴 11.5%
solx-compiler-downloader	🔴 0.0%	🔴 0.0%
solx-core	🔴 39.2%	🔴 46.9%
solx-dev	🔴 2.4%	🔴 3.0%
solx-evm-assembly	🔴 0.0%	🔴 0.0%
solx-mlir	🟡 50.3%	🔴 46.3%
solx-slang	🔴 22.6%	🔴 31.0%
solx-solc-test-adapter	🔴 1.7%	🔴 2.1%
solx-standard-json	🔴 42.6%	🔴 47.7%
solx-tester	🔴 36.1%	🔴 34.3%
solx-utils	🔴 32.3%	🔴 35.1%
solx-yul	🔴 0.0%	🔴 0.0%
Total	🔴 10.9%	🔴 13.1%

Codecov Report | HTML Report | Workflow Run

[Copilot]

Copilot review overview

🟡 Changes recommended

Constructor-chain construction introduces a prohibited hierarchy pre-pass and threaded cache.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Avoid precomputing constructor hierarchy; resolve lazily during emission · New
• Make the unused base fallback declaration abstract

[Copilot]

Copilot review overview

🟡 Changes recommended

Selector dispatch is still precomputed before emission, contrary to the frontend’s required on-demand model.

Get a fresh assessment by requesting another Copilot review.

Review effort: Balanced
Findings: 1 · 1

Open (2)

• Avoid eager selector pre-pass; derive eligibility during emission · New
• Rename identifier binding to node_id · New

Resolved since last review (2)

• Avoid precomputing constructor hierarchy; resolve lazily during emission
• Make the unused base fallback declaration abstract

[abinavpp]

thank you for working on this!

This is pre-existing, but what does the Object enum in solx-slang/src/contract/object.rs buy us over slang's own definitions? Object::functions(), state_variables() and storage_layout() are now thin wrappers over linearised_functions(), linearised_state_variables() and compute_abi(), and the library cases are the plain node.functions() / node.state_variables(). If I read functions() right, the extra walk over contracts() is only there to emit in linearisation/declaration order rather than slang's name order

[abinavpp]

thank you! lgmt! mostly nits/questions. i don't see any major concerns with the lowering..

[ggiraldez]

I left some minor suggestions and questions, but looks good to me! Can't really evaluate the MLIR part, but I can see Abinav already approved as well.

[hedgar2017]

This is pre-existing, but what does the Object enum in solx-slang/src/contract/object.rs buy us over slang's own definitions? Object::functions(), state_variables() and storage_layout() are now thin wrappers over linearised_functions(), linearised_state_variables() and compute_abi(), and the library cases are the plain node.functions() / node.state_variables(). If I read functions() right, the extra walk over contracts() is only there to emit in linearisation/declaration order rather than slang's name order

@abinavpp I'd keep Object, it provides a nice abstraction over matches that would have to be inlined otherwise, since ContractDefinition and LibraryDefinition are different types.
On the order, however, it makes sense to emit in Slang order and I've confirmed it doesn't affect behavior. We've just had a lot of LIT pinned against solc that would have to be changed.

Let me create an issue for a follow-up. I'd address it after solc removal: #726