-
Notifications
You must be signed in to change notification settings - Fork 28
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
feat/constrain-ids #466
Merged
Merged
feat/constrain-ids #466
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kanej
force-pushed
the
feat/constrain-ids
branch
2 times, most recently
from
September 13, 2023 22:06
8e459a0
to
9e93069
Compare
We are limiting the user provided ids for builder actions to alphanumeric/underscores/dashes. This is to support filenames on windows.
The elements we use to build the id should be limited in such a way that we can write them out as filenames on windows. We constrain contract names to alphanumerics/underscore/dollar sign. We similarly constrain function names. Though function names had to be loosened to allow for the `myfun(uint256,bool)` syntax we support.
The id is provided as a parameter. We don't need a second overriding id in this case.
Move the individual future id generators into its own module and put it under test.
Also remove underscores from Ignition identifiers.
We now use the same rule for namespacing the a call/staticCall action as we use for other actions. If the user provides an id, the only namespacing is to the module (rather than the module/contract as it was before).
Modify our id separators, swapping: - `:` => `#` - `#` => `.` This allows us to write the identifiers as filenames on windows. Resolves #441.
kanej
force-pushed
the
feat/constrain-ids
branch
from
September 14, 2023 10:04
9e93069
to
ba6d5bc
Compare
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We do not enforce any rules on the types of ids that can be used for modules or actions. This is a problem because we use those ids when writing to the file system (including on windows).
This PR introduces rules on module ids, user provided action ids and all of the components that can be used as fallbacks to generate an id.
Module ids and user provided action ids are only allowed to start with a letter and then include only alphanumerics and underscores:
The contract names, event names, args are validated based on Solidity's identifier rules:
Function names and event names are slightly looser than the Solidity identifier rule to support ethers style function/event + params
myfun(uint256,bool)
:With constraints on the parts that are used to build up the surrogate ids, and by ensuring our combination separators are valid we can ensure that all our ids are valid for filenames on windows/linux.
As such we are changing the separator symbols to those that can work as windows filenames, specifically:
:
->#
#
->.
This PR also:
MyModule#Call1
for user provided ids matching the other rulesReview
I would suggest taking the commits in order. The first commits refactor our code to pull the id and validation code into one place. The final commit swaps the separators (but this ends up touching quite a few files, mainly tests).