-
Notifications
You must be signed in to change notification settings - Fork 3.1k
SI-9080 Replace Cloneable/Serializable traits with type aliases #5288
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
Looks like we need to bootstrap the compiler between changing Definitions and removing the files... |
@soc, we like this, but RC1 is very close. Can you propose a plan to get this green by the end of next week without releasing another STARR? |
I don't see one. Definitions assumes real, existing Scala classes. This has to be fixed before the Scala classes can be removed in favor of aliases. Another thing that I would like to see is dropping the |
@soc What steps could I take to reproduce the problem? |
@retronym Replace the classes with aliases in the same step, without building a new STARR. Compiler will crash. |
I see, the STARR compiler fails with:
|
@retronym This one should compile, but as mentioned, I think the "package" in |
You probably need to get rid of |
I fixed the issue in scalap/caseClass, although I don't even want to know why it's
|
@retronym What do you think of the need for I added a few of them to make things compile, but I think either all or none of the collection classes should get the annotations. Opinions? Edit: Forgot the test in question, it is https://github.com/scala/scala/blob/2.12.x/test/files/run/t8549.scala#L117 |
// We could actually omit this marker interface as LambdaMetaFactory will add it if | ||
// the FLAG_SERIALIZABLE is set. | ||
// But the code is cleaner if we uniformly add a single marker, so I'm leaving it in place. | ||
private val Serializable = "java.io.Serializable" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@smarter Thanks! I simplified things, could you have a look whether I should go further and get rid of this completely? As I understand, there now no benefit anymore of doing it, as the only marker we add is already added automatically.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@retronym can probably answer this better than me
Can we disable scaladoc generation for this one?
|
Let's continue work on this, but I think we should do this under a bigger umbrella of library cleanups in 2.13. 2.12.0-RC1 is too close. |
Well, it's just waiting for a merge. After that, we need a new bootstrap, and then the final change, removing the traits, can be merged, fixing the scaladoc error. |
Any news on this? |
No, this will have to go into 2.13. I don't want the RC cycle to slip further. |
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
Fixes scala/bug#9080. This commit is adapted from scala#5288 and is thus: Co-authored-by: Simon Ochsenreither <[email protected]>
No description provided.