You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Check realizability of parameters of an erased function
... instead of checking every instantiated instance of erasedValue[T].
I think this is the better solution, since erasedValue have uses outside
of erasedDefinitions (i.e. in inlining) which has their own realizability checks
as well. We don't have to be pessimistic in those cases.
- Only check for realizability for erased parameters of result-dependent functions.
Per talk with @odersky, it seems that it is enough to check for
realizability of parameters of a dependent function in order to avoid
unsoundness.
Note that the following actions have already been checked for,
with erased parameters:
- Using them as a dependent path in casting / variable definitions
- Using them as the input to an `inline match`
The check previously performed on `val`/`def` definitions are also
removed, so we are as liberal as possible, to avoid too much restriction.
I think with this, we can also remove the special case for `compiletime.erasedValue`.
if!tree.symbol.isOneOf(TermParamOrAccessor) &&!tree.symbol.eq(defn.Compiletime_erasedValue) then// Only need to check non-parameters, since parameters have their own path checks.
493
-
// We want all erased definitions to have a realizable type
0 commit comments