Feature: Versioning

[Sdoba16]

Project

compiler

Motivation

1. In the future, SimplicityHL will likely introduce non-backward-compatible changes.
2. Even if the language syntax remains identical, the generated CMR might change across different SimplicityHL versions. If smart contract developers do not notice the compiler update, compiling new contracts that interact with older deployed contracts could result in locking user funds.
3. Smart contract audits are inherently tied to specific compiler versions to guarantee complete security and deterministic compilation.

To solve these problems, we need to add strict, built-in compiler versioning to the head of every .simf file.

Describe the feature

Each .simf file must declare a compiler version requirement at the very top (e.g., simc ">=0.6.0").

This version will be parsed in a preprocessing step before the full AST is constructed. The compiler will scan from the top of the file, safely skipping comments. When it encounters the first actual code, it will check if it is a version directive. If the directive is missing, the compiler will throw an error message. If it is present, it will verify compatibility against the currently running compiler using standard SemVer rules. This step will be done for all dependencies.

Implementation plan:

1. Update the lexer and parser to cleanly extract and read the version directive at the start of the file.
2. Read the compiler's actual version from Cargo.toml at build time for comparisons.
3. Throw precise semantic errors if there is a mismatch (e.g., clearly distinguishing between "Compiler too old" and "Contract too old").

[stringhandler]

This is actually possible already with asdf-vm. You just need to create .tool-versions file with

simc 0.4.0

[stringhandler]

asdf is not supported on windows though. I was looking at mise as an alternative.

[stringhandler]

Do you have an example of a contract that is not backwards compatible?

[Sdoba16]

Do you have an example of a contract that is not backwards compatible?

I don't have an exact contract example, but I mean "Not backward compatible" in the context of future updates. If we find out some vulnerabilities in special version(e.g. jets vulnerability), in this case we will need to forbid usage of vulnerable versions and show warning to user. Old contracts relying on those removed jets would no longer be backwards compatible with the new compiler.

This is actually possible already with asdf-vm. You just need to create .tool-versions file with

simc 0.4.0

This is good tool for developers managing environments natively, but for external users it is not the best option. We do not want to force user to interact with compiler. The user could just write pragma version X.Y.Z in source code and the tooling will automatically manage it(or show version incompatibility error).

[apoelstra]

We should also confirm that we're at a state now where we want to commit to maintaining the language in that state forever. (Sounds like we've deployed some stuff so "yes" but we should be explicit about it.)