-
Notifications
You must be signed in to change notification settings - Fork 471
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
AVM: Modify StackType to provide additional information #5130
AVM: Modify StackType to provide additional information #5130
Conversation
4a0bcb3
to
e54d4e7
Compare
b3f54fb
to
bff9876
Compare
…s/Returns, fix some tests to use avm type for comparison
bff9876
to
ee56f94
Compare
Codecov Report
@@ Coverage Diff @@
## master #5130 +/- ##
==========================================
+ Coverage 53.78% 55.35% +1.57%
==========================================
Files 450 454 +4
Lines 56201 63898 +7697
==========================================
+ Hits 30226 35373 +5147
- Misses 23626 26127 +2501
- Partials 2349 2398 +49
... and 397 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
…tself and expose the immediates by name in the langspec.json file
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.
I have to go to a meeting, so this isn't much feedback yet. Main idea that I think would be helpful is if we didn't have to name some of these types. It forced you to shoehorn some things into "hash" or "addr" that really aren't. I'd rather they appear in docs as [32]byte
(which would still be a nice improvement over []byte
.
I wonder about some others, like key
and bigint
, would they be better as [..64]byte
or something like that? I haven't yet seen, but I assume you have a new section in docs that explains these types?
Co-authored-by: Bob Broderick <[email protected]>
…lgorand into avm-stack-type-definition
…lgorand into avm-stack-type-definition
7e0a097
to
80c2fb4
Compare
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.
Seems like a good improvement, I just have minor comments
| any | | any | | ||
| address | len(x) == 32 | []byte | | ||
| []byte | len(x) <= 4096 | []byte | | ||
| [32]byte | len(x) == 32 | []byte | |
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.
Should we remove the [32]byte
line and just hard code a line like:
| [N]byte | len(x) == N | []byte |
I'd probably remove the method
time and use [4]byte
directly if we did that.
Just looking for thoughts, no need to make changes here. I want to get this in.
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.
Looks good, just one nit, but still looks good to merge
} | ||
|
||
func (st StackType) constant() (uint64, bool) { | ||
if st.Bound[0] == st.Bound[1] { |
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: I think this function should return false if the stack type is any, based on prior discussion
This pr modifies the existing
StackType
to allow more precise specification of types, especially those that are common, including a name and value or length bounds.e.g.
address
is a[]byte
that is exactly 32 bytes longboolean
is auint64
that is in the range 0-1 (inclusive)This change also has the benefit of allowing some additional assembly time checks. For example the TEAL snippet
should fail at assembly time because the byte string we're passing couldn't possibly be an address type.
Major Changes:
StackType
is now calledavmType
and is a member of the newStackType
struct.proto
function that provides typing for the ops has been updated to account for the newStackTypes
OpSpec
s have had theirproto
argument updated to denote they work on the more specific type.Field
specs have been updated to specify that they return the more specific type.opdoc
program has been updated to make use of the new types and fully document them in the langspec and README