-
Notifications
You must be signed in to change notification settings - Fork 43
More bindings fixes driven by Sourcify test runs #1350
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
More bindings fixes driven by Sourcify test runs #1350
Conversation
Literal fixed arrays now inherit the type of the first item; this allows extension methods to bind on them.
…'s lexical scope
This is to support the pattern `address(uint160(to)).transfer(...)` found in several Ethereum Mainnet contracts.
…e()` expressions
🦋 Changeset detectedLatest commit: cdeea64 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 |
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 few questions, otherwise LGTM! 🚀
|
||
|
||
;;; String expressions | ||
@expr [Expression [StringExpression]] { |
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.
This mechanism only works for strings? Shouldn't there be a similar thing for other types?
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.
I think all types for literal expressions are covered by now, but through different commits and in different PRs (eg. c2a7c64)
@@ -2543,6 +2545,25 @@ inherit .star_extension | |||
edge @type_expr.output -> typeof | |||
edge typeof -> type | |||
edge type -> @type_expr.lexical_scope | |||
|
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.
does it make sense to try to abstract this with the typeof(enum) case?
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.
Not really. Both apply in different contexts (ie. the enum definition vs. the type()
expression), but more importantly, the version where min/max
are valid are different.
@@ -1331,13 +1331,19 @@ inherit .star_extension | |||
;; @id_path.rightmost_identifier which corresponds to the identifier in the last | |||
;; position in the path, from left to right. This is used in the using directive | |||
;; rules to be able to pop the name of the attached function. | |||
;; |
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.
Is there a case of the form X.Y.z where this can arise? (More than one period). Is this handled?
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.
We need the push_ns
node to be able to navigate in the graph to where the modifier is. It doesn't matter how many components are in the namespace part of the modifier invocation, so this should be handled.
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.2.1 ### Patch Changes - [#1377](#1377) [`f3b51be`](f3b51be) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Bind untyped tuple deconstruction elements as references, not declarations - [#1335](#1335) [`6c3ad5d`](6c3ad5d) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Top-level `ConstantDefinition`s now bind to their type and resolve extension functions called on them - [#1338](#1338) [`18be0bc`](18be0bc) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Make try/catch parameters and vars in for loop initialization available in Yul - [#1339](#1339) [`f16e4b5`](f16e4b5) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Fixes to the binding rules in Solidity: - Make the `.length` member available in all static-size byte arrays - Allow assembly blocks (and nested Yul functions) to access inherited state variables - Allow assembly blocks access to constructor/modifier/fallback parameters - `msg.sender` is of `address` type (not `payable`) until 0.5.0 - Top-level constants need to be visible from assembly blocks in files that import them - Resolve named arguments when calling an extension function - Imported symbols using deconstruction syntax can be bound in assembly blocks - [#1353](#1353) [`8e718dd`](8e718dd) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Fixes to the binding rules in Solidity: - Values of the deprecated `byte` type have a `length` member until 0.8.0 - Bind a qualified identifier in the same contract, ie. `Foo.x` in a method body of `Foo` - Correctly bind external constants and built-ins in nested functions in assembly blocks - Literal boolean values should bind to the `bool` type to chain extension functions - Public state variables the generate getters should have members of external functions (such as `.selector`) - Event types have a `selector` member - [#1326](#1326) [`045179b`](045179b) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Fixes to binding rules: - Update `TupleDeconstructionStatement` so that their definiens is the `TypedTupleMember`/`UntypedTupleMember` for each variable declared. - Update `YulVariableDeclarationStatement` so that their definiens is the `YulIdentifier` for each variable declared. - [#1350](#1350) [`0594fe8`](0594fe8) Thanks [@ggiraldez](https://github.com/ggiraldez)! - Fixes to bindings rules in Solidity: - Allow binding of `using` directives inside interfaces in Solidity < 0.7.1 - Bind literal fixed arrays types - Fix generating binding graph for built-ins: remove the `memory` location specifier from types so they bind properly - Fix return type of `value()` and `gas()` legacy call options to allow chaining them - Bind legacy call options in the result of `new` expressions - Bind output type of public getters when the state variable is a nested mapping or array - A `using` directive with the `global` modifier should impact the source unit's lexical scope - Relax the Solidity version where the `transfer()` method works for non-payable addresses; this is a workaround for a Solidity quirk that makes it possible to do `address(uint160(to)).transfer(amount)` even after 0.5.0 - Fix bound return types of `wrap()` and `unwrap()` methods of a user value defined type - Resolve the type of `min()` and `max()` of `type()` expressions for integer types to the integer type given in the expression operand - Fix binding of fully qualified modifier invocations - Fix #1321: `min()` and `max()` for `type()` expressions on `enum` types should bind only after Solidity 0.8.8 - Bound type for literal number expressions is `uint256` by default; this allows correctly binding extension methods operating on literal values - The type `bytes` is an array type and should bind the `push()` and `pop()` methods - Contract or interface reference values implicitly inherit from the `address` type on Solidity < 0.5.0 - Modifiers are allowed inside interfaces until Solidity 0.8.8 and thus should properly bind and be accessible from inheriting contracts - Libraries before Solidity 0.5.0 allowed `this` in function methods and work as an `address` type Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Followup to #1339
More fixes to bindings rules in Solidity:
using
directives inside interfaces in Solidity < 0.7.1memory
location specifier from types so they bind properlyvalue()
andgas()
legacy call options to allow chaining themnew
expressionsusing
directive with theglobal
modifier should impact the source unit's lexical scopetransfer()
method works for non-payable addresses; this is a workaround for a Solidity quirk that makes it possible to doaddress(uint160(to)).transfer(amount)
even after 0.5.0wrap()
andunwrap()
methods of a user value defined typemin()
andmax()
oftype()
expressions for integer types to the integer type given in the expression operandtype(Enum).min
andtype(Enum).max
#1321:min()
andmax()
fortype()
expressions onenum
types should bind only after Solidity 0.8.8uint256
by default; this allows correctly binding extension methods operating on literal valuesbytes
is an array type and should bind thepush()
andpop()
methodsaddress
type on Solidity < 0.5.0this
in function methods and work as anaddress
typeThe PR is quite big, but all commits should be self contained and can be reviewed individually.