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

Support emitting Java 9 bytecode by adding "-target:9" #8060

Merged
merged 1 commit into from Jun 28, 2019

Conversation

hrhino
Copy link
Member

@hrhino hrhino commented May 15, 2019

A resurrection of @mkurz's #6146 (in the sixes!) that drops support for 1.7 and under, and gives the option of -target:jvm-9 for symmetry with -target:jvm-1.8, but prefers -target:9 (as a combination of @retronym's and @SethTisue's suggestions on that PR). Well, it still prefers -target:jvm-1.8 over either, but it can be persuaded to change its mind.

The sole effect of this flag is to emit bytecode that breaks on Java 8, which @SethTisue points out would be a useful feature. The hope is that it can be used also to enable various features which are impossible on versions later than 8, if we so desire.

I'm prepared to accept criticism, pushback, and outright insults based on at least these bases:

  • should we also have -target:10 and -target:11?
    • should we additionally also have -target:jvm-10 &c.?
  • should we not have the jvm- variant at all?
  • should I have kept the previous versions? (I hope not!)
  • is this a good idea at all?

@retronym
Copy link
Member

jvm- is something of a historical artifact of the time there was also msil- (the .NET backend). IMO we should align with javac now, and primarily use -target:9 etc. If it's easy to do, we can still support jvm- prefixed targets for backwards compat.

@@ -45,12 +47,15 @@ trait StandardScalaSettings {
val nowarn = BooleanSetting ("-nowarn", "Generate no warnings.") withAbbreviation "--no-warnings"
val optimise: BooleanSetting // depends on post hook which mutates other settings
val print = BooleanSetting ("-print", "Print program with Scala-specific features removed.") withAbbreviation "--print"
val target = ChoiceSettingForcedDefault ("-target", "target", "Target platform for object files. All JVM 1.5 - 1.7 targets are deprecated.",
List("jvm-1.5", "jvm-1.6", "jvm-1.7", "jvm-1.8"), "jvm-1.8") withAbbreviation "--target"
val target = ChoiceSetting ("-target", "target", "Target platform for object files.", List("jvm-1.8", "jvm-9", "9"), "jvm-1.8") withPostSetHook fixupTarget _ withAbbreviation "--target"
Copy link
Member

@retronym retronym May 15, 2019

Choose a reason for hiding this comment

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

How abuot we just advertise "1.8", "9", ... here, and rig up this setting to strip off the jvm- part before the contains call in ChoiceSetting.

      case List(x) if choices contains x  => value = x ; SomeOfNil
 = ChoiceSetting  ("-target", "target", "Target platform for object files.", List("jvm-1.8", "jvm-9", "9"), "jvm-1.8").withPostSetHook(fixupTarget).withPreSetHook(_.stripPrefix("jvm-")).withAbbreviation("--target")

(where withPreSetHook is a new method on ChoiceSetting)

Copy link
Member Author

@hrhino hrhino Jun 1, 2019

Choose a reason for hiding this comment

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

Adding a method to ChoiceSetting from this class is apparently non-trivial.

@@ -74,6 +74,7 @@ abstract class BackendUtils extends PerRunInit {

lazy val classfileVersion: LazyVar[Int] = perRunLazy(this)(compilerSettings.target match {
case "jvm-1.8" => asm.Opcodes.V1_8
case "9" => asm.Opcodes.V9
Copy link
Member

Choose a reason for hiding this comment

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

I'd extend this at least to 11.

@hrhino hrhino force-pushed the topic/jvm-9 branch 2 times, most recently from 8ffdb99 to 6093cff Compare June 1, 2019 02:24
@hrhino
Copy link
Member Author

hrhino commented Jun 1, 2019

As the (new) commit message says, "I got annoyed with all of the abstract types and such involved in the settings cake with the stated goal of enabling an immutable Settings object which is nearly a decade in the making. It's enough to make me lose a bit of faith, and therefore I've trimmed down the amount of abstraction going on here."


import scala.language.higherKinds

trait AbsScalaSettings {
Copy link
Member

Choose a reason for hiding this comment

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

💯

val unchecked = BooleanSetting ("-unchecked", "Enable additional warnings where generated code depends on assumptions.") withAbbreviation "--unchecked"
val uniqid = BooleanSetting ("-uniqid", "Uniquely tag all identifiers in debugging output.") withAbbreviation "--unique-id"
val usejavacp = BooleanSetting ("-usejavacp", "Utilize the java.class.path in classpath resolution.") withAbbreviation "--use-java-class-path"
val usemanifestcp = BooleanSetting ("-usemanifestcp", "Utilize the manifest in classpath resolution.") withAbbreviation "--use-manifest-class-path"
val verbose = BooleanSetting ("-verbose", "Output messages about what the compiler is doing.") withAbbreviation "--verbose"
val version = BooleanSetting ("-version", "Print product version and exit.") withAbbreviation "--version"

final val MinTargetVersion = 8
final val MaxTargetVersion = 12 // this one goes to twelve
Copy link
Member

Choose a reason for hiding this comment

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

Let's make these non-constants in case some separately compiled client code wanted to depend on updated values.

@@ -106,7 +106,7 @@ object ScalaOptionParser {
"-Ymacro-expand" -> List("discard", "none"),
"-Yresolve-term-conflict" -> List("error", "object", "package"),
"-g" -> List("line", "none", "notailcails", "source", "vars"),
"-target" -> List("jvm-1.5", "jvm-1.6", "jvm-1.7", "jvm-1.8"))
"-target" -> List("jvm-1.8", "jvm-9", "9"))
Copy link
Member

Choose a reason for hiding this comment

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

Needs to go up to 12 as well.

It would be great if we could resurrect https://github.com/scala/scala-tool-support/blob/master/bash-completion/src/main/scala/BashCompletion.scala to dynamically generate the completion data for Bash and for sbt scalac ... as well.

Copy link
Member

Choose a reason for hiding this comment

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

Just remembered we now have sbt generateDocsData which generates compiler-options.yml containing all the data we would need. So the "it would be great" thing would now to be that data into the our parser for sbt scalac and to transform that data into a bash completion script.

@SethTisue SethTisue added the release-notes worth highlighting in next release notes label Jun 18, 2019
Copy link
Member

@retronym retronym left a comment

Choose a reason for hiding this comment

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

  • Avoid constants for things that will change
  • Update SBT option parser to go up to 12.

I got annoyed with all of the abstract types and such involved in the
settings cake with the stated goal of enabling an immutable `Settings`
object which is nearly a decade in the making. It's enough to make me
lose a bit of faith, and therefore I've trimmed down the amount of
abstraction going on here.

I'm sure that if we ever do get around to that refactor, this won't be
that hard to reinstate.

Co-Authored-By: Matthias Kurz <m.kurz@irregular.at>
@retronym retronym merged commit c5431b0 into scala:2.13.x Jun 28, 2019
@mr-git
Copy link

mr-git commented Sep 18, 2019

and we have 13 already now, at time, when 2.13.1 gets released... and 14 (LTS) is coming in 6 month...
Will Scala support compilation at 13, 14 (LTS) (15, 16, 17 (LTS)) in 2.13.2+?

@SethTisue
Copy link
Member

and we have 13 already now, at time, when 2.13.1 gets released... and 14 (LTS) is coming in 6 month...

Will Scala support compilation at 13, 14 (LTS) (15, 16, 17 (LTS)) in 2.13.2+?

a few relevant tickets:

pull requests in this area are welcome

@lrytz
Copy link
Member

lrytz commented Oct 10, 2019

In a recent internal discussion, @dwijnand clarified that Java 14 is not LTS, the next LTS release will be 17:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release-notes worth highlighting in next release notes
Projects
None yet
6 participants