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

Improve support for Scala 3 code generation through Scalameta dialects #63

Merged
merged 4 commits into from
Jan 24, 2025

Conversation

sbrunk
Copy link
Contributor

@sbrunk sbrunk commented Jan 24, 2025

  • Improve support for Scala 3 code generation using Scalameta dialects during printing
  • Use literal types for refined, adding Scala 3 support and dropping 2.12 for this module
    • Also removes the shapeless dependency used for encoding literal types before
  • Cross compile and run sbt scripted tests for Scala 2.13 and 3

This also reverts the hack to use uppercase enums from #62, as it's not needed anymore.

Reasoning for using dialects only during printing

Scalameta uses dialects to express differentes between Scala versions. Quasiquotes need the dialect to be fixed at compile time via import. As it runs during compile time, we can't parameterize it with a dialect dynamically. This is something we can't do here, as we want to dynamically toggle the output variant, depending on the Scala version of the project using the plugin.

On the other hand, we have a lot of code gen blocks using quasiquotes. We also have tons of Scala 2 syntax in our tests.

So to help keeping changes in check, we keep Scala 2 syntax in our quasiquote literals and in tests for now, i.e. we parse q"import io.circe._"), and only apply the dialect during pretty printing. This works fine for most things where the AST is the same. I.e. imports have the same AST representation in Scala 2 and 3, even though the syntax is different.

Also remove the hack to uppercase enums in #62, as that's not needed anymore.

Quasiquotes need the dialect to be fixed at compile time via import.
As it runs during compile time, we can't parameterize it with a dialect.
This is something we can't do here, as we want to dynamically toggle
the output variant, depending on the scala version of the project using
the plugin.

So to help keeping changes in check, we keep Scala 2 syntax in our quasiquote
literals, i.e. we parse q"import io.circe._"), and only apply the dialect during
pretty printing, which works for most things where the AST is the same.
I.e., imports have the same AST representation.
@sbrunk sbrunk requested a review from a team January 24, 2025 09:44
@sbrunk
Copy link
Contributor Author

sbrunk commented Jan 24, 2025

Not sure where this ghost build job is coming from: image

Copy link

@msvaljek msvaljek left a comment

Choose a reason for hiding this comment

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

Looks o.k.

I'm not sure if the toUpperCase removals change maybe something for the users of the generated code 🤔 - if this is o.k. then 👍

@sbrunk
Copy link
Contributor Author

sbrunk commented Jan 24, 2025

I'm not sure if the toUpperCase removals change maybe something for the users of the generated code 🤔 - if this is o.k. then 👍

It's the other way around fortunately. We introduced the uppercasing in #63 which isn't part of any release, but would have impacted code with heavy use of enums. I'm reverting that here to reduce the potential impact.

@msvaljek
Copy link

I'm not sure if the toUpperCase removals change maybe something for the users of the generated code 🤔 - if this is o.k. then 👍

It's the other way around fortunately. We introduced the uppercasing in #63 which isn't part of any release, but would have impacted code with heavy use of enums. I'm reverting that here to reduce the potential impact.

thanks for the context - makes sense now 🙇

Copy link
Collaborator

@adrobisch adrobisch left a comment

Choose a reason for hiding this comment

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

👌

@sbrunk sbrunk merged commit 7050455 into main Jan 24, 2025
6 checks passed
@sbrunk sbrunk deleted the scala3-codegen branch January 24, 2025 10:45
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