solidity
solidity copied to clipboard
Visiting type class bodies in experimental analysis
~Depends on #14566.~
This adds "pass 3" as described in Experimental Type System Notes, which is responsible for collecting types of type class member functions.
I also moved builtin class registration to TypeClassRegistration
, though builtin classes are going to be removed soon (we'll instead have specific class members marked as builtin).
Based on our discussions on the call and on the chat today, here's how I understand what needs to be done in this PR next:
-
Keep it as a separate pass.
-
Create a helper for a specific use case pattern of unification for typing function applications
Unification is pretty much the most basic operation on types there is - so we should have more helpers for specific patterns involving unification, in particular for the "function application" pattern...
- E.g. a unification helper that gives you the return type of a function given its generic type and concrete argument types. Currently that usually done ad-hoc inline.
- If there are any other uses for types, they could also be separate helpers needed only in the new pass.
- The
if (!m_activeInstantiations.empty())
block inTypeInference::unify()
should become unnecessary after the PR and can be removed.
-
Visit function definitions, including the whole parameter list and return type.
- The new pass should have a copy of the
type
annotation (maybe use a more specific name to keep things clear). - Anything needed to fill the
type
annotation of a function definition inside a type class should be moved to the new pass. Forunify()
use the new helpers. - Basically everything from
TypeInference::visit(TypeClassDefinition)
should be moved, including the unification. - The unification should give us a complete type, with no type variables other than the class variable (validate that).
- The back and forth visitation between type classes and the instantiation is no longer necessary.
- Also keep the current logic of visiting non-class functions in type inference.
- The new pass should have a copy of the
-
Move all the visitation in type and sort context to the new pass
- We don't really need the distinction between type and sort context. Do it inline and remove the context mechanism.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.
This pull request is stale because it has been open for 14 days with no activity.
It will be closed in 7 days unless the stale
label is removed.