-
Notifications
You must be signed in to change notification settings - Fork 42
Fix #1375: untyped tuple deconstruction statements are assignments #1377
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
Conversation
… 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.
🦋 Changeset detectedLatest commit: ea378cc 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.
Thank you!
@@ -2024,7 +2024,7 @@ inherit .star_extension | |||
node @tuple_decon.defs | |||
} | |||
|
|||
@tuple_decon [TupleDeconstructionStatement [TupleDeconstructionElements | |||
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements |
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 suggestion: matching comment:
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements | |
;; Tuple deconstruction statements with var keyword are declarations | |
@tuple_decon [TupleDeconstructionStatement [VarKeyword] [TupleDeconstructionElements |
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>
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.