Skip to content
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

Typechecking case classes is not idempotent #5467

Closed
scabug opened this issue Feb 14, 2012 · 3 comments
Closed

Typechecking case classes is not idempotent #5467

scabug opened this issue Feb 14, 2012 · 3 comments
Assignees
Labels

Comments

@scabug
Copy link

scabug commented Feb 14, 2012

In the majority of cases typechecking replaces arbitrary trees that represent types with their TypeTree() equivalents that have the "tpe" fields that hold the compiled types and the "original" fields that hold the original trees with assigned symbols.

Case classes are no exception. Once plain and symless, after typechecking ValDefs have their tpts changed into TypeTrees. Thanks to originals, TypeTrees are friendly to resetAllAttrs, so everything seems to be fine. However, part of the implementation of case classes employs the violent UnTyper that erases the tpes without looking into originals. Trees that undergo such brutal treatment cannot be typechecked anymore.

Another source of non-idempotency is the whole synthetic business. Even if a case class or a case companion already have certain members, subsequent typechecking will try to add them again, resulting in conflicts and, ultimately, compilation errors.

@scabug
Copy link
Author

scabug commented Feb 14, 2012

Imported From: https://issues.scala-lang.org/browse/SI-5467?orig=1
Reporter: @xeno-by
Affected Versions: 2.10.0
Blocks #5464

@scabug
Copy link
Author

scabug commented Dec 6, 2012

@xeno-by said:
See tests introduced in scala/scala@5028181

@SethTisue
Copy link
Member

consolidating under #5464

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants