Refinements to realizability #5568
Conversation
I had a TypeError crash in refchecks after screwing up a typeclass encoding in a particularly bad way. This commit reports an error instead.
Add the rule T <: Any for any *-Type T. This was not include fully before. We
did have the rule that T <: Any, if Any is in the base types of T. However,
it could be that the base type wrt Any does not exist. Example:
Any#L <: Any
yielded false before, now yields true. This error manifested itself in i4031.scala.
With the new rule, we can drop again the special case in derivedSelect.
|
test performance please |
|
performance test scheduled: 1 job(s) in queue, 0 running. |
|
Something wrong with the CI? Test output for bootstrapped after 17.06 minutes is and nothing else. |
|
Performance test finished successfully: Visit http://dotty-bench.epfl.ch/5568/ to see the changes. Benchmarks is based on merging with master (ce62b37) |
Unstable types can still be realizable (i.e. if their underlying type is concrete with no bad bounds).
|
Turns out, #4031 was not a bug (or, rather, not a bug that should be fixed before we track nullability). Keeping the rest of this PR since it refines realizability in useful ways. |
| if (tp1.isLambdaSub) return false | ||
| if (cls2 eq AnyClass) return true | ||
| // Note: We would like to replace this by `if (tp1.hasHigherKind)` |
There was a problem hiding this comment.
This comment is now attached to the wrong line (it refers to isLambdaSub above)
|
@Blaisorblade I propose the following order to finish with realizability: You do a quick review of #5568 and we merge it. Then we rebase #5558 on top of the merged master and I review that one in turn. Sounds good? |
There was a problem hiding this comment.
LGTM.
For the record, I was worried because paths ending in unstable symbols can now be considered realizable — but we assume that paths are separately checked for stability. Indeed, paths written in source code appear to be checked via checkStable (if not, that should be fixed separately). realizability(tp) must still test isStable because tp might not arise from paths in the source code, but overall this seems sufficient.
This was another attempt to fix #4031 without breaking other things, before I found out that
it was not a fixable bug, after all. Keeping the bits that are still of value.
Supersedes #4036 and #5559.