| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The statement `val x = this` in the refinment type:
(new {}): {val x = this}
is lazily typechecked, in order to, according to the comment
in `typedRefinment, "avoid cyclic reference errors".
But the approximate type used ends up with:
Refinment@1(
parents = [...]
decls = { val x: Refinement@1 })
This commit eagerly checks that there is no term definitions
in type refinments, rather than delaying this.
This changes the error message for SI-3614.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When an error occurs because some type does not conform
to AnyRef (and an AnyRef-derived type would have sufficed)
try to say something useful about the situation.
This commit also initializes scope members before printing
error messages because the + version seems more useful than
the - version (taken from one of the checkfile diffs.)
- def <init>: <?>
- def methodIntIntInt: <?>
+ def <init>(): X
+ def methodIntIntInt(x: scala.Int,y: scala.Int): scala.Int
|
|
|
Closes SI-5305.
This reverts a few lines of e5cfe47a19, which was a remedy for SI-3614 and SI-3856*. I added a test case for the former, the
latter was already tested. Both tests pass after this change, and they do so with the old and new pattern matcher.
But does this change still "avoid trees with null types in presentation compiler"? What was the intent of the context hopping in the first place?
* Based on this comment: https://issues.scala-lang.org/browse/SI-3614?focusedCommentId=50477&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-50477, which elaborates further than the commit comment of e5cfe47a19.
|
