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

reflect: fully implement Type.AssignableTo #4376

Draft
wants to merge 2 commits into
base: dev
Choose a base branch
from
Draft

Conversation

aykevl
Copy link
Member

@aykevl aykevl commented Jul 31, 2024

This fully implements AssignableTo, fixing a number of bugs in the previous implementation. In particular, it now supports AssignableTo for interface types.

Depends on #4375

This is a big reimplementation that simplifies the compiler a lot.
Instead of storing the method set in metadata and lowering the type
asserts as a whole program pass, this change just puts the list of
methods in the type code (and a separate global for the interface type).
This fully implements AssignableTo, fixing a number of bugs in the
previous implementation. In particular, it now supports AssignableTo for
interface types.
@@ -65,7 +65,6 @@ func Optimize(mod llvm.Module, config *compileopts.Config) []error {

// Run TinyGo-specific optimization passes.
OptimizeStringToBytes(mod)
OptimizeReflectImplements(mod)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So what happens with type asserts that are statically known to be true or false? Optimization pushed for future work?

Copy link
Member Author

@aykevl aykevl Aug 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is specifically for the reflect Implements method, which is used in some important code but not really used that much in total (so I don't think optimizing it will provide much benefit). The main reason this "optimization" existed was to get the encoding/json package to work.

But yeah, good point about other (normal Go style) interface type asserts. I can do a check how common that is and whether optimizing that case is beneficial. That is something that should work well as a package level optimization though.

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.

2 participants