cquiroz / sbt-locales

Plugin to produce locales dbs
BSD 3-Clause "New" or "Revised" License
11 stars 13 forks source link

Compilation errors in Scala 3 and -indent -new-syntax #252

Open Lasering opened 1 year ago

Lasering commented 1 year ago

Similar to https://github.com/cquiroz/sbt-tzdb/issues/154. Using the plugin in a Scala 3 project with the following scalacOptions:

scalacOptions ++= Seq(
    "-indent",                       // Allow significant indentation.
    "-new-syntax",                   // Require `then` and `do` in control expressions.
    "-feature",                      // Emit warning and location for usages of features that should be imported explicitly.
    "-language:future",              // better-monadic-for
    "-deprecation",                  // Emit warning and location for usages of deprecated APIs.
    "-Werror",                       // Fail the compilation if there are any warnings.
    "-source:future",
)

Causes the managed sources to fail compilation.

A similar approach to what was implemented in sbt-tzdb could be made. Although in this repo the PR is slightly more involved as it requires the base setup/infrastructure to first be built.

If this is something you would be willing to support and I can do a PR.

cquiroz commented 1 year ago

For sure I'd review a PR if you're interested to submit one

Lasering commented 1 year ago

Started to investigate how to go about it. The sbt-tzdb has the "managed sources" directly on src/main/resources of the sbt-tzdb sbt project. Whereas sbt-locales has a whole new project in the api folder whose sources are added as resources of the sbt-locales sbt project. The api project is being cross compiled. This poses a challenge:

Currently the code is the same for JVM, JS, and Native. However I would need two sets of code: the one as it exists now, and another for scala3-future. Changing to CrossType.Full wouldn't solve the problem. Leading me to think another api project would be necessary, but at the same time this approach does not feel clean. Do you have a better idea how to solve this?

Lasering commented 1 year ago

@cquiroz any thoughts on the above?

cquiroz commented 1 year ago

Sorry I've been quite busy lately, I'll try to take a look soon

cquiroz commented 1 year ago

I thin the difference is because on locales there is no api to get locales data unlike tzdb where there is the concept of service provider in the java api. Thus we need the api project to let scala-java-locales load the locale info, Can we make all code scala3-future?

Lasering commented 1 year ago

Can we make all code scala3-future?

No, because the code would be included in the users projects as managed sources.