Skip to content

Unhelpful error message for type erasure #23350

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

Open
threeseed opened this issue Jun 10, 2025 · 0 comments
Open

Unhelpful error message for type erasure #23350

threeseed opened this issue Jun 10, 2025 · 0 comments
Labels
area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:enhancement

Comments

@threeseed
Copy link

threeseed commented Jun 10, 2025

Compiler version

3.7.0

Minimized example

import scala.scalajs.js

abstract class A:
  type Props
  def apply(p: Props) = ()

type UndefOr2[A] = A | Unit
object D extends A:
  case class Props()
  def apply(a: UndefOr2[String]) = ()

Output Error/Warning message

Name clash between defined and inherited member:
def apply(p: A.this.Props): Unit in class A at line 7 and
def apply(a: Playground.UndefOr2[String]): Unit in object D at line 27
have the same type after erasure.

Consider adding a @targetName annotation to one of the conflicting definitions
for disambiguation 

Why this Error/Warning was not helpful

It doesn't tell me what the "same type" actually is.

Suggested improvement

Ideally it would be something like this:

We need to have the class be the "least specific" type it can be in the bytecode.
For A: there's an invisible >: Nothing <: Any, meaning the least specific type is Any for which the class is Object.
For D: the type is SomeCaseClass | Unit, for which the shared class is Object
As both A and D are of type Object they are in conflict.

Consider adding a @TargetNAME annotation to either A or D.

@threeseed threeseed added itype:enhancement area:reporting Error reporting including formatting, implicit suggestions, etc stat:needs triage Every issue needs to have an "area" and "itype" label better-errors Issues concerned with improving confusing/unhelpful diagnostic messages labels Jun 10, 2025
@Gedochao Gedochao removed the stat:needs triage Every issue needs to have an "area" and "itype" label label Jun 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:reporting Error reporting including formatting, implicit suggestions, etc better-errors Issues concerned with improving confusing/unhelpful diagnostic messages itype:enhancement
Projects
None yet
Development

No branches or pull requests

2 participants