-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
Adjust polymorphicInstance()
#14635
Adjust polymorphicInstance()
#14635
Conversation
test/libsolidity/syntaxTests/experimental/inference/polymorphic_function_call_via_variable.sol
Outdated
Show resolved
Hide resolved
The funny thing is: the last thing I did before pushing the prototype was to do the exact opposite :-) - i.e. to introduce |
Why would it be any easier to replace |
The point was to collect all instances of refreshening for the purpose of generating a polymorphic schema of a global definition and then checking what's left. Also: producing a freshened type is a technical operation on the type - producing a polymorphic instance of a global type scheme is a semantic description of what's happening. |
Based on that I'd actually not remove it. (Removing the entire function that gives the operation that happens here a descriptive name is quite different from removing the additional type variable it unnecessarily introduces :-)) |
58e6b99
to
2ab295f
Compare
polymorphicInstance()
with fresh()
polymorphicInstance()
|
2ab295f
to
781a73b
Compare
I need reapproval. Only pushed a small stylistic tweak. |
Before we merge new changes, we first need to clean up the mess in the base branch. |
a9bf87f
to
bc86754
Compare
acef62d
to
8c31a4f
Compare
8c31a4f
to
5db6e6c
Compare
5db6e6c
to
0162b8e
Compare
I wanted to merge this already, but in that case maybe I should still change it before I do? |
No hurry, just bringing up the option. |
@@ -481,7 +480,10 @@ experimental::Type TypeInference::handleIdentifierByReferencedDeclaration(langut | |||
else if (dynamic_cast<FunctionDefinition const*>(&_declaration)) | |||
return polymorphicInstance(*declarationAnnotation.type); | |||
else if (dynamic_cast<TypeClassDefinition const*>(&_declaration)) | |||
return polymorphicInstance(*declarationAnnotation.type); | |||
{ | |||
solAssert(TypeEnvironmentHelpers{*m_env}.typeVars(*declarationAnnotation.type).empty()); |
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.
Wait, what? That doesn't seem right - shouldn't there be exactly one variable in there?
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.
Ah, no, this is term context, so the use of the type class name as a special concrete type with its functions attached as members... I hope the distinction will become clearer after the upcoming refactors, we'll see.
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.
So fine with merging the PR?
…ic-instance Adjust `polymorphicInstance()`
…ic-instance Adjust `polymorphicInstance()`
…ic-instance Adjust `polymorphicInstance()`
The PR addresses #14510 (comment) and #14510 (comment).
We discussed this last week on the call -
unifyGeneralized()
was a part of some idea that was not fully realized in the end and all we really need is just a call toTypeEnvironment::fresh()
. That's whatpolymorphicInstance()
does now.The PR also adds some tests covering the uses of
fresh()
andpolymorphicInstances()
. This shows that the PR does not break things both here and with my subsequent changes in #14606.