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

Modification via a type alias failing on Scala 3 #97

Merged

Conversation

OndrejSpanel
Copy link
Contributor

Another Scala 3 regression. Following code fails to compile:

  case class State(x: Int)

  type S = State

  val s: S = State(0)
  val modified = s.modify(_.x).setTo(1)

  modified.x shouldBe 1

The error is:

Unsupported source object: must be a case class or sealed trait, but got: type S

I think hopefully I should be able to prepare a fix.

@KacperFKorban
Copy link
Collaborator

KacperFKorban commented Sep 1, 2022

It most likely just needs a dealias call after tpe at line 163.

EDIT: nvm, it actually requires a bunch of .widen.dealias calls 😅

@OndrejSpanel
Copy link
Contributor Author

I have added a commit inverting the case class / sealed trait logic. Anything which does not require a special handling is handled as a case class, hoping it will behave like one.

This does not fix the issue yet, but it could make the code a bit more robust when handing unexpected situations.

it actually requires a bunch of .widen.dealias calls

I will try to drop some at random source location and see where it works. 😊

@KacperFKorban
Copy link
Collaborator

It's pretty much before any .typeSymbol call

@KacperFKorban
Copy link
Collaborator

I have added a commit inverting the case class / sealed trait logic. Anything which does not require a special handling is handled as a case class, hoping it will behave like one.

I'm not sure if that's what we want. The condition for Case was in place because we need a copy to be able to rewrite normal field accesses (not to mention the default methods).
Also, the error message was quite clear. In this case, it was a bug (because of an obvious error of mine) but other times it might be helpful.

@OndrejSpanel OndrejSpanel force-pushed the pr-unsupported-source-object branch from f2d3d4e to 0a1f8c5 Compare September 1, 2022 14:26
@OndrejSpanel
Copy link
Contributor Author

Also, the error message was quite clear. In this case, it was a bug (because of an obvious error of mine) but other times it might be helpful.

OK. I will leave that out. It is certainly not needed for the fix and it is not related, therefore I should not have mixed it here.

@OndrejSpanel OndrejSpanel force-pushed the pr-unsupported-source-object branch from 0a1f8c5 to 3d14033 Compare September 1, 2022 14:32
@OndrejSpanel
Copy link
Contributor Author

Tests pass. I think the PR should be ready for review / merge.

@OndrejSpanel OndrejSpanel marked this pull request as ready for review September 1, 2022 14:35
Copy link
Collaborator

@KacperFKorban KacperFKorban left a comment

Choose a reason for hiding this comment

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

I added a suggestion with a test case for the other case (sealed tarit/enum) that would still fail.
I cannot add comments there, but two more .widen.dealias calls will be needed before accessing .typeSymbol.children.

@OndrejSpanel OndrejSpanel force-pushed the pr-unsupported-source-object branch from dfc6e1c to 9802d63 Compare September 1, 2022 15:05
@adamw adamw merged commit 2b28a9a into softwaremill:master Sep 1, 2022
@OndrejSpanel OndrejSpanel deleted the pr-unsupported-source-object branch September 2, 2022 07:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants