Skip to content
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

Merged
merged 104 commits into from
Jan 4, 2023

Conversation

charles-cooper
Copy link
Member

@charles-cooper charles-cooper commented Dec 8, 2022

What I did

For historical reasons, vyper models its type system in two places, in vyper/semantics/types and vyper/codegen/types. this merges the two systems (w/ plenty of pair programming help from @z80dev)

also:

  • rename ModuleNodeVisitor to ModuleAnalyzer
  • move the VariableRecord class to vyper/codegen/context.py
  • simplify GlobalContext.parse_type and a lot of associated machinery

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

Put a link to a cute animal picture inside the parenthesis-->

@lgtm-com
Copy link
Contributor

lgtm-com bot commented Dec 8, 2022

This pull request introduces 4 alerts and fixes 5 when merging 8d817b9 into e60b021 - view on LGTM.com

new alerts:

  • 3 for Unused import
  • 1 for Missing call to `__init__` during object initialization

fixed alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for 'import *' may pollute namespace

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.

@lgtm-com
Copy link
Contributor

lgtm-com bot commented Dec 8, 2022

This pull request introduces 6 alerts and fixes 5 when merging d6ed7d0 into e60b021 - view on LGTM.com

new alerts:

  • 6 for Unused import

fixed alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for 'import *' may pollute namespace

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.

@lgtm-com
Copy link
Contributor

lgtm-com bot commented Dec 8, 2022

This pull request introduces 6 alerts and fixes 5 when merging 5a224a0 into 44bb434 - view on LGTM.com

new alerts:

  • 6 for Unused import

fixed alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for 'import *' may pollute namespace

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.
@lgtm-com
Copy link
Contributor

lgtm-com bot commented Dec 8, 2022

This pull request introduces 7 alerts and fixes 5 when merging b349a36 into 44bb434 - view on LGTM.com

new alerts:

  • 7 for Unused import

fixed alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for 'import *' may pollute namespace

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.

@charles-cooper
Copy link
Member Author

@fubuloubu @skellet0r this is ready for review. @z80dev to do a final look over as well.

Copy link
Collaborator

@tserg tserg left a 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.

vyper/codegen/context.py Outdated Show resolved Hide resolved
vyper/codegen/expr.py Show resolved Hide resolved
Copy link
Contributor

@skellet0r skellet0r left a 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!

Copy link
Member

@fubuloubu fubuloubu left a 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

vyper/builtins/_convert.py Show resolved Hide resolved
Comment on lines +34 to +51
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)
Copy link
Member

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?

Copy link
Member Author

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.

Comment on lines +54 to +66
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
Copy link
Member

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?

Copy link
Member

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

Copy link
Member Author

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.

Copy link

@github-advanced-security github-advanced-security bot left a 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.

@charles-cooper charles-cooper merged commit 3abe588 into vyperlang:master Jan 4, 2023
@charles-cooper charles-cooper deleted the refactor/typechecker branch January 4, 2023 21:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants