-
Notifications
You must be signed in to change notification settings - Fork 42
infer_language_versions
api
#1265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
infer_language_versions
api
#1265
Conversation
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 detectedLatest commit: cf5ad63 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
crates/solidity/outputs/cargo/crate/src/extensions/semver/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/parser.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/parser.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/parser.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/semver/parser.rs
Outdated
Show resolved
Hide resolved
return Ok(()); | ||
} else if !inferred_versions.contains(&version) { | ||
events.version_inference_error(format!( | ||
"[{version}] Did not find correct version for {path}", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"[{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.
crates/codegen/runtime/cargo/crate/src/runtime/parser/parser.rs.jinja2
Outdated
Show resolved
Hide resolved
crates/codegen/runtime/cargo/wasm/src/runtime/interface/parser.wit.jinja2
Outdated
Show resolved
Hide resolved
crates/codegen/runtime/cargo/crate/src/extensions/semver/mod.rs
Outdated
Show resolved
Hide resolved
crates/codegen/runtime/cargo/crate/src/runtime/parser/parser.rs.jinja2
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of suggestions, but otherwise looks good to me!
crates/solidity/outputs/cargo/crate/src/extensions/utils/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/utils/version/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/utils/version/mod.rs
Outdated
Show resolved
Hide resolved
crates/testlang/outputs/cargo/crate/src/extensions/utils/mod.rs
Outdated
Show resolved
Hide resolved
…anguage_versions` stubs
…he custom `VersionIterator`
crates/solidity/outputs/cargo/crate/src/extensions/utils/version/mod.rs
Outdated
Show resolved
Hide resolved
crates/solidity/outputs/cargo/crate/src/extensions/utils/version/mod.rs
Outdated
Show resolved
Hide resolved
@@ -11,5 +11,9 @@ interface utils { | |||
|
|||
/// Returns the latest language version supported by Slang. | |||
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/// 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. |
|
||
## 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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
|
||
/// 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>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: suggest using the same parameter names as the Rust API:
infer-language-versions: static func(src: string) -> list<string>; | |
infer-language-versions: static func(input: string) -> list<string>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of suggestions, but LGTM otherwise.
Thank you!
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>
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:
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.
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.