internal: don't instantiate concepts when lifting types #861
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Don't instantiate invocations of generic concepts when lifting types
(
liftParamType
). Instead, only turn the invocation into atyUserTypeClassInst
type.This removes a usage of
semtypinst
's "meta-types allowed" mode, and isthus a step towards removing the latter.
Details
Instead of using
instGenericContainer(allowedMetaTypes = true)
forlifting the invocation of generic concepts into a
tyUserTypeClassInst
,the invocation is now copied, transitioned to a
tyUserTypeClassInst
,and then has the underlying
tyUserTypeClass
the invocation applies toadded as the last element.
The above is not the same as what
instGenericContainer
did. Mostimportantly, generic invocations used as arguments to the invocation
are not instantiated. In practice, this means that a parameter type like
Concept[Generic[T]]
will reachtypeRel
and subsequentlymatchUserTypeClass
as(UserTypeClassInst (...) (GenericInvocation (...) (...)) (...))
instead of as
(UserTypeClassInst (...) (GenericInst (...) (...) (...)) (...))
The
tyGenericInvocation
has thetfHasMeta
flag included and atyInferred
is thus later created when matching against the concept,which is correct. Since
typeRel
does support resolvingtyInferred
types that have a
tyGenericInvocation
as the base, this doesn't causeproblems.