Skip to content

Conversation

ggiraldez
Copy link
Contributor

@ggiraldez ggiraldez commented Jun 4, 2025

Followup to #1339

More 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 Bindings: incorrect version adding support for type(Enum).min and type(Enum).max #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

The PR is quite big, but all commits should be self contained and can be reviewed individually.

ggiraldez added 18 commits June 3, 2025 15:53
Literal fixed arrays now inherit the type of the first item; this allows
extension methods to bind on them.
This is to support the pattern `address(uint160(to)).transfer(...)` found in
several Ethereum Mainnet contracts.
@ggiraldez ggiraldez requested review from a team as code owners June 4, 2025 02:06
Copy link

changeset-bot bot commented Jun 4, 2025

🦋 Changeset detected

Latest commit: cdeea64

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 Patch

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

Copy link
Contributor

@beta-ziliani beta-ziliani left a 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]] {
Copy link
Contributor

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?

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor Author

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.
;;
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@ggiraldez ggiraldez enabled auto-merge June 26, 2025 22:22
@ggiraldez ggiraldez added this pull request to the merge queue Jun 26, 2025
Merged via the queue into NomicFoundation:main with commit 0594fe8 Jun 26, 2025
2 checks passed
@ggiraldez ggiraldez deleted the sourcify-bindings-fixes-2 branch June 26, 2025 22:55
@github-actions github-actions bot mentioned this pull request Jun 26, 2025
github-merge-queue bot pushed a commit that referenced this pull request Jul 21, 2025
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 &lt;
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 &lt; 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bindings: incorrect version adding support for type(Enum).min and type(Enum).max
3 participants