-
-
Notifications
You must be signed in to change notification settings - Fork 793
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
refactor: merge front-end and codegen type systems #3182
refactor: merge front-end and codegen type systems #3182
Conversation
This pull request introduces 4 alerts and fixes 5 when merging 8d817b9 into e60b021 - view on LGTM.com new alerts:
fixed alerts:
Heads-up: LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine ⚙️ that powers LGTM.com. For more information, please check out our post on the GitHub blog. |
This pull request introduces 6 alerts and fixes 5 when merging d6ed7d0 into e60b021 - view on LGTM.com new alerts:
fixed alerts:
Heads-up: LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine ⚙️ that powers LGTM.com. For more information, please check out our post on the GitHub blog. |
This pull request introduces 6 alerts and fixes 5 when merging 5a224a0 into 44bb434 - view on LGTM.com new alerts:
fixed alerts:
Heads-up: LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine ⚙️ that powers LGTM.com. For more information, please check out our post on the GitHub blog. |
the is_literal_bytes32_assign was dead code from the days when one could assign a literal bytestring of length 32 (i.e. b"111...11") to a variable with type bytes32.
This pull request introduces 7 alerts and fixes 5 when merging b349a36 into 44bb434 - view on LGTM.com new alerts:
fixed alerts:
Heads-up: LGTM.com's PR analysis will be disabled on the 5th of December, and LGTM.com will be shut down ⏻ completely on the 16th of December 2022. Please enable GitHub code scanning, which uses the same CodeQL engine ⚙️ that powers LGTM.com. For more information, please check out our post on the GitHub blog. |
This reverts commit 0efb1db.
This reverts commit 9585561.
@fubuloubu @skellet0r this is ready for review. @z80dev to do a final look over as well. |
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.
Amazing work sir, this greatly simplifies the type system and all the way through to testing.
Also, I really like the signeds
, unsigneds
and all
methods of the primitives.
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.
You really get an appreciation for the refactoring in expr.py and functions.py. Not seeing typ=BaseType(...)
or typ="..."
, really is a glory to behold. That and, type instance checks throughout the codebase becoming much clearer and concise really help readability.
Damn fine refactoring work!
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.
Pretty impressive refactor. Some small suggestions for improvement, but overall looks good to me
def is_bytes_m_type(typ): | ||
return isinstance(typ, BytesM_T) | ||
|
||
|
||
def is_numeric_type(typ): | ||
return isinstance(typ, (IntegerT, DecimalT)) | ||
|
||
|
||
def is_integer_type(typ): | ||
return isinstance(typ, IntegerT) | ||
|
||
|
||
def is_decimal_type(typ): | ||
return isinstance(typ, DecimalT) | ||
|
||
|
||
def is_enum_type(typ): | ||
return isinstance(typ, EnumT) |
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.
Would these make sense to inline for readability reasons?
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.
tried it both ways, but some sections of code just read more cleanly with the helper functions.
def is_tuple_like(typ): | ||
# A lot of code paths treat tuples and structs similarly | ||
# so we have a convenience function to detect it | ||
ret = isinstance(typ, (TupleT, StructT)) | ||
assert ret == hasattr(typ, "tuple_items") | ||
return ret | ||
|
||
|
||
def is_array_like(typ): | ||
# For convenience static and dynamic arrays share some code paths | ||
ret = isinstance(typ, (DArrayT, SArrayT)) | ||
assert ret == typ._is_array_type | ||
return ret |
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.
Are these codepaths just here to double-check that there are no other codepaths that produce a tuple or dynamic array?
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.
Also could inline these too if these were just to double-check
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.
the codepath is to double check that typ._is_array_type
means the same as membership in DArrayT, SArrayT
. it's a sanity check in case any future types break that assumption.
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.
CodeQL found more than 10 potential problems in the proposed changes. Check the Files changed tab for more details.
What I did
For historical reasons, vyper models its type system in two places, in
vyper/semantics/types
andvyper/codegen/types
. this merges the two systems (w/ plenty of pair programming help from @z80dev)also:
ModuleNodeVisitor
toModuleAnalyzer
VariableRecord
class tovyper/codegen/context.py
How I did it
How to verify it
Commit message
Commit message for the final, squashed PR. (Optional, but reviewers will appreciate it! Please see our commit message style guide for what we would ideally like to see in a commit message.)
Description for the changelog
Cute Animal Picture