`infer_language_versions` api by mjoerussell · Pull Request #1265 · NomicFoundation/slang

mjoerussell · 2025-03-04T23:37:52Z

Added a new API which generates a list of valid language versions for a Solidity source file by parsing the pragma solidity declarations.

Here's a basic example of how this API might be used:

let solidity_source = get_source();

let valid_versions = LanguageUtils::infer_language_versions(&solidity_source);

// Use the latest support version to parse the file
let parser = Parser::create(valid_versions.last());

As stated in the Solidity documentation, the semver parsing is based on npm's semver implementation. However, solc's implementation has had several bugs/undocumented features currently and in the past which we need to support.

Handling quotes within semvers (e.g. "0".8"" == "0.8")
Users can add operators to semvers inside hyphen ranges. These get ignored.
Users can add operators to partial version ranges. These are handled differently depending on the operator and how the partial version range was defined.
Parsing is overall a lot more permissive than a standard semver parser, and we need to be able to skip over some invalid inputs.

I've added 30 unit tests to the parser, each of which tests various positive and negative cases for different types of semvers. I've also included some of solc's test cases from here to ensure that we're passing/failing the same matches that they are.

This parser is trying to stick to npm's flavor of semver, which Solidity also uses for its version pragma

…g common syntax forms, and they are all passing. The biggest thing that's missing right now is handling Solidity's specific semver quirks and edge cases, which are definitely not handled.

…nts of a Solidity source file as input and shallowly parses it to pull out any version pragmas. It thencompares all of the pragmas to the full list of available versions and returns a list of all the versions which pass.

…urce files against the actual version used to compile them according to Sanctuary. I'm marking two kinds of version errors here: one for when we can't infer a version from a source file, and one for when the actual version is not included in the inferred versions list.

…d of Sanctuary testing. At first this was extacting the version pragmas by just going line-by-line and finding lines that start with `pragma solidity`. This is obviously an overly simplistic way to do this. One glaring issue here is that if a source file has a version pragma inside a block comment, then that would still be included in the list of pragmas that must be matched. This update uses slang's parser instead to extract all of the real version pragmas, and then the custom semver parser to do the rest. After making this change we have 0 version inference errors from Sanctuary.

…ators (`^` and `~`) in hyphen ranges. These two things don't make sense to be included together, and most likely a correct parser would fail to parse this range. However, Solidity does/has just ignored these operators in the case of a hyphen range, so we will do that too.

I copied the semver parsing/matching test cases from solc and recreated them here. From there I fixed any weird behaviors that weren't already handled. Most importantly, solc allows users to specify operators in front of partial version ranges, which leads to some unintuitive behavior.

…rly in some circumstances * Refactored the parser code to move the types and base implementations to `semver/mod.rs`, and all the parsing code in `semver/parser.rs`.

…ype of thing is getting parsed. Also trying to simplify/consolidate some of the higher-level parsing bits.

changeset-bot · 2025-03-04T23:37:55Z

🦋 Changeset detected

Latest commit: cf5ad63

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@nomicfoundation/slang	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

…otes are included

ggiraldez

Left a couple of suggestions, but the implementation looks good in general. I have two questions though:

Re: the internal version types, wouldn't it be possible to reuse the semver crate types? It's not too much code, but it seems redundant. What is preventing you from reusing them?
The parsing code also somewhat duplicates the main language parser, and IIUC, there are some cases accepted by this new parser that the language will not parse. Maybe we should not try to parse versions from the language definition at all. Or, on the opposite side, try to build the version ranges from the parsed CST nodes. WDYT?

ggiraldez · 2025-03-05T16:54:58Z

+            return Ok(());
+        } else if !inferred_versions.contains(&version) {
+            events.version_inference_error(format!(
+                "[{version}] Did not find correct version for {path}",


Suggested change

"[{version}] Did not find correct version for {path}",

"[{version}] Inferred versions do not match with reported for {path}",

* Add `has_known_version_mismatch` check to the sanctuary tests so that we skip files where the version in sanctuary is known to not match the version pragmas

… our purposes they're interchangable, all of the custom semver parsing/handling happens in `PartialVersion`, `Comparator`, and `ComparatorSet` - once we reduce the versions to concrete versions then we don't need anything special. This results in a bit less custom code.

…anguage_versions` stubs

…he custom `VersionIterator`

…nge`

…`Range`

stefanoban · 2025-03-19T11:49:52Z

        latest-version: static func() -> string;
+
+        /// Analyze the version pragmas within a source file, and return a list of supported language versions that match these pragmas.
+        /// If the source file contains no pragmas, all supported versions are returned.


Suggested change

/// If the source file contains no pragmas, all supported versions are returned.

/// If the source file contains no pragmas, all versions supported by Slang are returned.

stefanoban · 2025-03-19T11:50:52Z

+
+## Inferring Compatible Solidity Versions
+
+For cases where you don't know in advance which version of Solidity to use, the `LanguageFacts` API provides a utility to generate a list of compatible versions. It uses the [version pragmas](https://docs.soliditylang.org/en/develop/layout-of-source-files.html#version-pragma) defined in your Solidity source file to filter the list of versions supported by Slang, returning only the compatible ones.


Suggested change

For cases where you don't know in advance which version of Solidity to use, the `LanguageFacts` API provides a utility to generate a list of compatible versions. It uses the [version pragmas](https://docs.soliditylang.org/en/develop/layout-of-source-files.html#version-pragma) defined in your Solidity source file to filter the list of versions supported by Slang, returning only the compatible ones.

For cases where you don't know in advance which version of Solidity to use, the `LanguageFacts` API provides a utility to generate a list of compatible versions. It uses the [version pragmas](https://docs.soliditylang.org/en/develop/layout-of-source-files.html#version-pragma) defined in your Solidity source file to filter the list of versions supported by Slang, returning only the compatible ones. If the source file contains no pragmas, all versions supported by Slang are returned.

Co-authored-by: Omar Tawfik <15987992+OmarTawfik@users.noreply.github.com>

OmarTawfik · 2025-03-20T09:34:23Z

+
+        /// Analyze the version pragmas within a source file, and return a list of supported language versions that match these pragmas.
+        /// If the source file contains no pragmas, all versions supported by Slang are returned.
+        infer-language-versions: static func(src: string) -> list<string>;


nit: suggest using the same parameter names as the Rust API:

Suggested change

infer-language-versions: static func(src: string) -> list<string>;

infer-language-versions: static func(input: string) -> list<string>;

OmarTawfik

Left a couple of suggestions, but LGTM otherwise.
Thank you!

@OmarTawfik

This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @nomicfoundation/slang@1.1.0 ### Minor Changes - [#1288](#1288) [`2090ab8`](2090ab8) Thanks [@OmarTawfik](https://github.com/OmarTawfik)! - support Solidity `0.8.29` and [Custom Storage Layouts](https://docs.soliditylang.org/en/v0.8.29/contracts.html#custom-storage-layout): - `ContractDefinition` nodes will no longer have an optional `InheritanceSpecifier` child directly, but will hold a list of `ContractSpecifier` children - `ContractSpecifier` nodes have either `InheritanceSpecifier` or `StorageLayoutSpecifier` children - [#1265](#1265) [`2312260`](2312260) Thanks [@mjoerussell](https://github.com/mjoerussell)! - Add `LanguageUtils::infer_language_versions(source_code) -> Version[]` API, which will analyze version pragmas inside a source file, and return a list of supported language versions that they allow. This can be used to select a valid language version to use with the rest of Slang APIs. Please see the [Choosing a Solidity Version](https://nomicfoundation.github.io/slang/1.1.0/user-guide/04-getting-started/02-choosing-a-solidity-version/) guide for more information. ### Patch Changes - [#1291](#1291) [`da1f863`](da1f863) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Resolve arguments to inheritance specifiers and expressions in storage layout specifiers using the contract's parent scope. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

@OmarTawfik

This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @nomicfoundation/slang@1.1.0 ### Minor Changes - [#1288](NomicFoundation/slang#1288) [`2090ab8`](NomicFoundation/slang@2090ab8) Thanks [@OmarTawfik](https://github.com/OmarTawfik)! - support Solidity `0.8.29` and [Custom Storage Layouts](https://docs.soliditylang.org/en/v0.8.29/contracts.html#custom-storage-layout): - `ContractDefinition` nodes will no longer have an optional `InheritanceSpecifier` child directly, but will hold a list of `ContractSpecifier` children - `ContractSpecifier` nodes have either `InheritanceSpecifier` or `StorageLayoutSpecifier` children - [#1265](NomicFoundation/slang#1265) [`2312260`](NomicFoundation/slang@2312260) Thanks [@mjoerussell](https://github.com/mjoerussell)! - Add `LanguageUtils::infer_language_versions(source_code) -> Version[]` API, which will analyze version pragmas inside a source file, and return a list of supported language versions that they allow. This can be used to select a valid language version to use with the rest of Slang APIs. Please see the [Choosing a Solidity Version](https://nomicfoundation.github.io/slang/1.1.0/user-guide/04-getting-started/02-choosing-a-solidity-version/) guide for more information. ### Patch Changes - [#1291](NomicFoundation/slang#1291) [`da1f863`](NomicFoundation/slang@da1f863) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Resolve arguments to inheritance specifiers and expressions in storage layout specifiers using the contract's parent scope. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

@OmarTawfik

This PR was opened by the [Changesets release](https://github.com/changesets/action) GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or [setup this action to publish automatically](https://github.com/changesets/action#with-publishing). If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated. # Releases ## @nomicfoundation/slang@1.1.0 ### Minor Changes - [#1288](NomicFoundation/slang#1288) [`2090ab8`](NomicFoundation/slang@2090ab8) Thanks [@OmarTawfik](https://github.com/OmarTawfik)! - support Solidity `0.8.29` and [Custom Storage Layouts](https://docs.soliditylang.org/en/v0.8.29/contracts.html#custom-storage-layout): - `ContractDefinition` nodes will no longer have an optional `InheritanceSpecifier` child directly, but will hold a list of `ContractSpecifier` children - `ContractSpecifier` nodes have either `InheritanceSpecifier` or `StorageLayoutSpecifier` children - [#1265](NomicFoundation/slang#1265) [`2312260`](NomicFoundation/slang@2312260) Thanks [@mjoerussell](https://github.com/mjoerussell)! - Add `LanguageUtils::infer_language_versions(source_code) -> Version[]` API, which will analyze version pragmas inside a source file, and return a list of supported language versions that they allow. This can be used to select a valid language version to use with the rest of Slang APIs. Please see the [Choosing a Solidity Version](https://nomicfoundation.github.io/slang/1.1.0/user-guide/04-getting-started/02-choosing-a-solidity-version/) guide for more information. ### Patch Changes - [#1291](NomicFoundation/slang#1291) [`da1f863`](NomicFoundation/slang@da1f863) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Resolve arguments to inheritance specifiers and expressions in storage layout specifiers using the contract's parent scope. Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>

github-actions added 13 commits February 26, 2025 11:28

Initial version of semver parsing.

e54b782

This parser is trying to stick to npm's flavor of semver, which Solidity also uses for its version pragma

Semver parsing is basically working now. I have ~10 test cases testin…

5f36dc1

…g common syntax forms, and they are all passing. The biggest thing that's missing right now is handling Solidity's specific semver quirks and edge cases, which are definitely not handled.

Refactoring/cleaning up parsing code, adding some documentation

f9b46a0

* Fixed an issue where parse errors could not be recovered from prope…

ce37974

…rly in some circumstances * Refactored the parser code to move the types and base implementations to `semver/mod.rs`, and all the parsing code in `semver/parser.rs`.

Run infra ci/formatter

ae1386d

Sort found language versions before returning them

0ae9872

Add some more test cases for the semver parser

dc333c0

Refactoring parse code to handle errors the same way no matter what t…

ddc3341

…ype of thing is getting parsed. Also trying to simplify/consolidate some of the higher-level parsing bits.

mjoerussell requested review from a team as code owners March 4, 2025 23:37

stefanoban requested review from OmarTawfik and ggiraldez March 5, 2025 12:21

Small refactor of is_whitespace and is_non_whitespace, explain why qu…

f46a73d

…otes are included

ggiraldez reviewed Mar 5, 2025

View reviewed changes

github-actions added 4 commits March 5, 2025 11:37

Cleanup code in infer_language_version

1632f7c

Move test code to a separate file

ca2d28e

* Add "check_infer_version" option to the sanctuary github workflows

282cf1d

* Add `has_known_version_mismatch` check to the sanctuary tests so that we skip files where the version in sanctuary is known to not match the version pragmas