Move pragma-specific keywords under dedicated topic #661
Conversation
|
| Keyword( | ||
| name = SolidityKeyword, | ||
| identifier = Identifier, | ||
| definitions = [KeywordDefinition(value = Atom("solidity"))] |
There was a problem hiding this comment.
I think this would also need creating a PragmaIdentifier as well for reservation, but I'm happy to tackle this separately after the migration is done. Will add a note for myself.
There was a problem hiding this comment.
Don't think there are any identifiers in pragmas, but we can separate that for clarity.
There was a problem hiding this comment.
There is an Identifier in ExperimentalFeature. Having a dedicated PragmaIdentifier will also force us to think about how the other three keywords affect the reservation of the original Identifier .. But I'm happy to tackle this after the migration, and add some integration tests for it with solc.
|
Ah, my bad then!
I tested it briefly and those three keywords didn’t seem to be reserved in
the default context but you never know with Solidity 🥲
…On Mon, 20 Nov 2023 at 23:22, Omar Tawfik ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In crates/solidity/inputs/language/src/definition.rs
<#661 (comment)>
:
> @@ -200,6 +200,21 @@ codegen_language_macros::compile!(Language(
Atom("*")
]))
)]
+ ),
+ Keyword(
+ name = SolidityKeyword,
+ identifier = Identifier,
+ definitions = [KeywordDefinition(value = Atom("solidity"))]
There is an Identifier in ExperimentalFeature. Having a dedicated
PragmaIdentifier will also force us to think about how the other three
keywords affect the reservation of the original Identifier .. But I'm
happy to tackle this after the migration, and add some integration tests
for it with solc.
—
Reply to this email directly, view it on GitHub
<#661 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAXTFXLVLMZFTYEYWAWBNYDYFPJZBAVCNFSM6AAAAAA7OIGJB6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONBQHAYDEOJSHA>
.
You are receiving this because you modified the open/close state.Message
ID: ***@***.***>
|
Split from #650
We talked about this recently at our stand-up.
These are never reserved in the default context and are only used in the (lexical) context of pragmas, so let's reflect that in the spec.
Not updating v1 in this context since #650 is about to obsolete that and v0 does not have lexical contexts that might be impacted.