-
Notifications
You must be signed in to change notification settings - Fork 196
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(cli): allow static arrays as abi types in store config and tablegen #509
Conversation
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.
Very cool! Nothing blocking, just two questions.
// When type inference sees multiple uses of 1 generic, it can only guess | ||
// which of those are supposed to define the generic (and it will be wrong in complex situations). | ||
// This helper explicitly makes a type that's dependent on some generic, | ||
// and will not be inferred as the generic's definition. | ||
export type AsDependent<T> = T extends infer P ? P : never; |
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.
What's an example for this?
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.
check out parseStoreConfig.test-d.ts
// WARNING: ensure this still works if changing major solidity versions! | ||
// (the memory layout for static arrays may change) |
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.
How can we remind ourselves of this when changing major solidity versions? Maybe a comment in cli's foundry.toml
?
Now that schema types are strings of abi types, I can make e.g.
uint32[2]
just work, without user typesAlso added some more tests
An annoying regression here is a bunch of
function mutability can be restricted to pure
warnings.Memory.copy
uses identity precompile, which forcesview
. And detecting which vars use such memory copying is a lot of needless complexity I'd rather avoid.This can be solved by changing
Memory.copy
(would likely cost more gas), or generalizingTightCoder
to be usable directly for static arrays (would sidestep the need for copying altogether).Regardless, for
Memory.copy
it would be best to use the native MCOPY if it ever happens: https://eips.ethereum.org/EIPS/eip-5656related: ethereum/solidity#12127
Also fixed a type inference bug which would happen in some complex configs with multiple user types