-
Couldn't load subscription status.
- Fork 15
Add examples to test partial eta-expansion #2
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
Conversation
|
I think you meant to open that against https://github.com/lampepfl/dotty, not https://github.com/dotty-staging/dotty/ |
|
Ah, I see you wanted to merge this into an open PR, in that case I'll just give you access to the dotty-staging repo so you can push to the branch directly. |
|
Wow, thanks @smarter! |
#2 (Missed another widenSingleton in PatternMatcher)
When desugaring pattern matching code for expressions where the
matched value has type `Null` or `Nothing`, we used to generate code
that's type-incorrect.
Example:
```
val Some(x) = null
```
got desugared into
```
val x: Nothing =
matchResult1[Nothing]:
{
case val x1: Null @unchecked = null: Null @unchecked
if x1.ne(null) then
{
case val x: Nothing = x1.value.asInstanceOf[Nothing]
return[matchResult1] x: Nothing
}
else ()
return[matchResult1] throw new MatchError(x1)
}
```
There were two problems here:
1) `x1.ne(null)`
2) `x1.value`
In both cases, we're trying to invoke methods that don't exist for type
`Nothing` (and #2 doesn't exist for `Null`).
This commits changes the desugaring so that
1) is solved by adding an ascription, if needed: (x1: AnyRef).ne(null)
2) is added by generating throw-away but type-correct code that never
executes: `throw null`
Integrate the spec of union and intersection types.
Update docs canthrow.md remove bad type alias at line 70
`given ... with` or `given ... = new { ... }` kinds of definitions now follow
the old rules. This allows recursive `given...with` definitions as they are
found in protoQuill.
We still have the old check in a later phase against directly recursive methods.
Of the three loops in the original i15474 we now detect #2 and #3 with new new
restrictions. #1 slips through since it is a loop involving a `given...with` instance
of `Conversion`, but is caught later with the recursive method check.
Previously tests #1 and #3 were detected with the recursive methods check and #2 slipped
through altogether.
The new rules are enough for defining simple givens with `=` without fear of looping.
`given ... with` or `given ... = new { ... }` kinds of definitions now follow
the old rules. This allows recursive `given...with` definitions as they are
found in protoQuill.
We still have the old check in a later phase against directly recursive methods.
Of the three loops in the original i15474 we now detect #2 and #3 with new new
restrictions. #1 slips through since it is a loop involving a `given...with` instance
of `Conversion`, but is caught later with the recursive method check.
Previously tests #1 and #3 were detected with the recursive methods check and #2 slipped
through altogether.
The new rules are enough for defining simple givens with `=` without fear of looping.
`given ... with` or `given ... = new { ... }` kinds of definitions now follow
the old rules. This allows recursive `given...with` definitions as they are
found in protoQuill.
We still have the old check in a later phase against directly recursive methods.
Of the three loops in the original i15474 we now detect #2 and #3 with new new
restrictions. #1 slips through since it is a loop involving a `given...with` instance
of `Conversion`, but is caught later with the recursive method check.
Previously tests #1 and #3 were detected with the recursive methods check and #2 slipped
through altogether.
The new rules are enough for defining simple givens with `=` without fear of looping.
`given ... with` or `given ... = new { ... }` kinds of definitions now follow
the old rules. This allows recursive `given...with` definitions as they are
found in protoQuill.
We still have the old check in a later phase against directly recursive methods.
Of the three loops in the original i15474 we now detect #2 and #3 with new new
restrictions. #1 slips through since it is a loop involving a `given...with` instance
of `Conversion`, but is caught later with the recursive method check.
Previously tests #1 and #3 were detected with the recursive methods check and #2 slipped
through altogether.
The new rules are enough for defining simple givens with `=` without fear of looping.
Add more tests as suggested in scala#2235.