Skip to content

Typer fixes #5017

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
Closed

Typer fixes #5017

wants to merge 13 commits into from

Conversation

Blaisorblade
Copy link
Contributor

WIP fixing #5008 and #5010.

Check if we inherit from scala.Enum both directly (as a result of the
desugaring) and indirectly.
To allow again t3613 to compile I need this exception. But the testcase is so
old I'm not sure if we should do this, even tho it's still supported by Scalac.
@@ -1529,6 +1529,7 @@ class Typer extends Namer
ctx.error(i"$psym is extended twice", tree.pos)
seenParents += psym
if (tree.isType) {
checkSimpleKinded(result) // Not needed for constructor calls, as type arguments will be inferred.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will they be inferred? I'm unconvinced that

class Siz[T](i: Int)
class Zle extends Siz(1)

and

class Siz[T]
class Zle extends Siz

should be treated differently w/r/t superclass targs.

@Blaisorblade
Copy link
Contributor Author

Blaisorblade commented Aug 25, 2018

(Since GitHub hides @hrhino's comment):

will they be inferred? I'm unconvinced that

class Siz[T](i: Int)
class Zle extends Siz(1)

and

class Siz[T]
class Zle extends Siz

should be treated differently w/r/t superclass targs.

Well T in Siz(1) will be inferred as in a normal method call (by interpolation).

If we want uniformity, we could also infer arguments to all parents, but that seems more error-prone, no?

EDIT: a better argument for the difference is that inference class Zle extends Siz seems never what you want, while inference in class Zle extends Siz(1) is the correct thing to do for most parents as class Siz[T](i: Int) seems artificial — or at least, if you're using it, you can expect inference problems. Also, I can imagine spec'ing this difference, while Dotty interpolation is much harder and tries to be pretty clever, so it's not spec'able (at least yet or by me).

This reverts commit 1fe1232 as it was an
incorrect diagnosis.
The only existing testcase was written when AbstractListModel had no parameter,
so change the testcase instead.

We could alternatively infer type arguments (see scala/bug#11111), but that
seems typically unhelpful.
Based on scala/scala@bed3304bf86 and Nicolas' suggestion.
@allanrenucci
Copy link
Contributor

@Blaisorblade Can you split the fix for enum into another PR?

@Blaisorblade
Copy link
Contributor Author

So the failure in http://dotty-ci.epfl.ch/lampepfl/dotty/7075/5 is because master is still broken by the Java 9 PR.

But this isn't a full fix and might be a bad idea.
@Blaisorblade
Copy link
Contributor Author

Split into #5027, #5028, #5029, #5030.

@Blaisorblade Blaisorblade reopened this Aug 26, 2018
Give
```
trait Foo
scala> val v = Foo
1 |val v = Foo
  |        ^^^
  |        not found: Foo
```
which is misleading because `Foo` exists, just as a type and not as a
value (we should maybe say "term" but Scala 2 uses "value").
`-Ycheck:all` is already handled by `containsPhase`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants