Skip to content

Fix #4031, v2: Check arguments of dependent methods for realizability (WIP) #5557

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

Closed
wants to merge 13 commits into from

Conversation

Blaisorblade
Copy link
Contributor

WIP rebase of #4031, finally. Still running tests.

abeln and others added 13 commits November 26, 2018 17:20
We were forgetting to check the prefix in the uncached case.
This change also caches stability for the affected code path.
After porting the commit from scala#4036, this line newly gives an error. Might be
OK, investigate.
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.

TODO: in the context of scala#4108, this seems questionable. Also, `Any#L` seems an
invalid type (even tho it is sound to consider it empty), and we'd probably not
want to accept it if the user writes it; here it is only OK because it's
introduced by avoidance. Or are user-written types checked elsewhere?
A TermRef is stable if its underlying type is stable. Realizability should
behave the same way. This obviates the change in z1720.scala.
I had a TypeError crash in refchecks after screwing up a typeclass encoding in a particularly bad way.
This commit reports an error instead.
I wrote this because I feared (incorrectly) exponential slowdowns in
realizability checking for this code. But debugging suggests that the
complexity of realizability checking is constant in the size of these
expressions (even after I disable caching of `Stable`).

Beware 1: these expressions almost smash the stack by sheer size.

Beware 2: this fails with `-Yno-deep-subtypes`, but simply because the checking
heuristics assumes people don't try to do this.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants