Skip to content

Conversation

ggiraldez
Copy link
Contributor

Fixes #1375

Except for Solidity < 0.5.0 with the var keyword. If the keyword is present, the statement should be treated as a declaration.

Caveat: because we don't validate code, it's possible to mix typed and untyped tuple elements and the binder will create declarations and references for each, but that's invalid Solidity code.

… assignments

Except for Solidity < 0.5.0 with the `var` keyword. If the keyword is present,
the statement should be treated as a declaration.

Caveat: because we don't validate code, it's possible to mix typed and untyped
tuple elements and the binder will create declarations and references for each,
but that's invalid Solidity code.
Copy link

changeset-bot bot commented Jul 14, 2025

🦋 Changeset detected

Latest commit: ea378cc

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

@ggiraldez ggiraldez marked this pull request as ready for review July 14, 2025 19:11
@ggiraldez ggiraldez requested review from a team as code owners July 14, 2025 19:11
@ggiraldez ggiraldez enabled auto-merge July 14, 2025 19:18
Copy link
Contributor

@OmarTawfik OmarTawfik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@@ -2024,7 +2024,7 @@ inherit .star_extension
node @tuple_decon.defs
}

@tuple_decon [TupleDeconstructionStatement [TupleDeconstructionElements
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit suggestion: matching comment:

Suggested change
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements
;; Tuple deconstruction statements with var keyword are declarations
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements

@OmarTawfik OmarTawfik disabled auto-merge July 14, 2025 19:29
@ggiraldez ggiraldez added this pull request to the merge queue Jul 15, 2025
Merged via the queue into NomicFoundation:main with commit f3b51be Jul 15, 2025
2 checks passed
@ggiraldez ggiraldez deleted the fix-1375 branch July 15, 2025 17:31
@github-actions github-actions bot mentioned this pull request Jul 15, 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.

Binding graph doesn't find references of variables used in tuple assignments
2 participants