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.

Sign up for GitHub

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

Jump to bottom

Unbreak sbt-dotty #779

Closed
dwijnand opened this issue May 6, 2020 · 5 comments · Fixed by #829 or #858
Closed

Unbreak sbt-dotty #779

dwijnand opened this issue May 6, 2020 · 5 comments · Fixed by #829 or #858
Milestone
1.4.0

Comments

@dwijnand
Copy link
Member

dwijnand commented May 6, 2020 •
edited by eed3si9n
Loading

The introduction of VirtualFile has impacted sbt-dotty, so this ticket tracks addressing that before 1.4.0.

See #712 (comment)

problem

The Dotty compiler cannot be instantiated:

[info] Compiling 1 Scala source to /home/adrien/Projects/mat3/target/scala-0.24/classes ...
[error] ## Exception when compiling 1 sources to /home/adrien/Projects/mat3/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
[error] sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[error] sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[error] sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[error] java.lang.reflect.Method.invoke(Method.java:498)
[error] sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:259)
[error] sbt.internal.inc.AnalyzingCompiler.newCachedCompiler(AnalyzingCompiler.scala:152)
[error] sbt.internal.inc.AnalyzingCompiler.newCachedCompiler(AnalyzingCompiler.scala:139)
[error] sbt.internal.inc.FreshCompilerCache.apply(CompilerCache.scala:103)
[error] sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:99)
[error] sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$5(MixedAnalyzingCompiler.scala:105)
[error] scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
[error] sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:198)
[error] sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:96)
[error] sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3$adapted(MixedAnalyzingCompiler.scala:85)
[error] sbt.internal.inc.JarUtils$.withPreviousJar(JarUtils.scala:226)
[error] sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:85)
[error] sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:162)
[error] sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:446)
[error] sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:446)
[error] sbt.internal.inc.Incremental$.doCompile(Incremental.scala:137)
[error] sbt.internal.inc.Incremental$.$anonfun$compile$6(Incremental.scala:111)
[error] sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:201)
[error] sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:110)
[error] sbt.internal.inc.Incremental$.$anonfun$compile$5(Incremental.scala:114)
[error] sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:176)
[error] sbt.internal.inc.Incremental$.compile(Incremental.scala:102)
[error] sbt.internal.inc.IncrementalCompile$.apply(IncrementalCompile.scala:82)
[error] sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:452)
[error] sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:401)
[error] sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:264)
[error] sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:347)
[error] sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:79)
[error] sbt.Defaults$.compileIncrementalTaskImpl(Defaults.scala:1885)
[error] sbt.Defaults$.$anonfun$compileIncrementalTask$1(Defaults.scala:1858)
[error] scala.Function1.$anonfun$compose$1(Function1.scala:49)
[error] sbt.internal.util.$tilde$greater.$anonfun$$u2219$1(TypeFunctions.scala:62)
[error] sbt.std.Transform$$anon$4.work(Transform.scala:67)
[error] sbt.Execute.$anonfun$submit$2(Execute.scala:282)
[error] sbt.internal.util.ErrorHandling$.wideConvert(ErrorHandling.scala:23)
[error] sbt.Execute.work(Execute.scala:291)
[error] sbt.Execute.$anonfun$submit$1(Execute.scala:282)
[error] sbt.ConcurrentRestrictions$$anon$4.$anonfun$submitValid$1(ConcurrentRestrictions.scala:184)
[error] sbt.CompletionService$$anon$2.call(CompletionService.scala:41)
[error] java.util.concurrent.FutureTask.run(FutureTask.java:266)
[error] java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[error] java.util.concurrent.FutureTask.run(FutureTask.java:266)
[error] java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[error] java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[error] java.lang.Thread.run(Thread.java:748)
[error]            
[error] stack trace is suppressed; run last Compile / compileIncremental for the full output
[error] (Compile / compileIncremental) java.lang.reflect.InvocationTargetException
[error] Total time: 1 s, completed 16-May-2020 08:41:05
@dwijnand dwijnand added this to the 1.4.0 milestone May 6, 2020
@dwijnand dwijnand mentioned this issue May 6, 2020
Merged
@dwijnand
Copy link
Member Author

dwijnand commented May 6, 2020

See the versioning PR #661

@eed3si9n eed3si9n mentioned this issue May 17, 2020
Closed
@bishabosha
Copy link

I'm currently working on migrating the dotty codebase so it can build with zinc 1.4, I could get around the VirtualFile break with a wrapper, but its still work in progress

eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 10, 2020
@eed3si9n
Reluctantly restore compatiblity of xsbti.*
0fbfce8 
Fixes sbt#779

As it stands, compiler-interface and compiler bridge implementation is an internal concern of Zinc implementation. We _should_ be able to remove methods or change the method signatures. The word "interface" here is between Scalac and Zinc internal, not to the world.

In reality, the situation is more complicated because we have Dotty compiler out there that is bound to specific version of compiler-interface. So when I released sbt 1.4.0-M1 this resulted in NoSuchMethodErrors:

```
[error] ## Exception when compiling 1 sources to /private/tmp/hello-dotty/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
....
[error] Caused by: java.lang.NoSuchMethodError: xsbti.compile.SingleOutput.getOutputDirectory()Ljava/io/File;
[error]   at xsbt.CachedCompilerImpl.<init>(CachedCompilerImpl.java:35)
```

To smooth things out, one approach we've discussed is to create a separate compiler-interface (in a different package) that is less dependent on Zinc specifics. Related to that, in sbt#661 I've created Java interface for `CompilerInterface1`, and we can use pattern matching to see which capability the compiler bridge implementation supports. This creates brings in those Java interfaces as well.

In any case, this commit brings back the old `java.io.File`-based methods, and locally I was able to get hello world from Dotty.
@eed3si9n eed3si9n mentioned this issue Jul 10, 2020
Merged
@eed3si9n
Copy link
Member

Here's my PR for this - #829

eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 10, 2020
@eed3si9n
Reluctantly restore compatibility of xsbti.*
8d33f54 
Fixes sbt#779

As it stands, compiler-interface and compiler bridge implementation are of internal concern of Zinc implementation. We _should_ be able to remove method or change the signatures. The word "interface" here is between Scalac and Zinc internal, not to the world.

In reality, the situation is more complicated because we have Dotty compiler out there that is bound to a specific version of compiler-interface. So when I released sbt 1.4.0-M1 this resulted in NoSuchMethodErrors:

```
[error] ## Exception when compiling 1 sources to /private/tmp/hello-dotty/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
....
[error] Caused by: java.lang.NoSuchMethodError: xsbti.compile.SingleOutput.getOutputDirectory()Ljava/io/File;
[error]   at xsbt.CachedCompilerImpl.<init>(CachedCompilerImpl.java:35)
```

To smooth things out, one approach we've discussed is to create a separate compiler-interface (in a different package) that is less dependent on Zinc specifics. Related to that, in sbt#661 I've created Java interface for `CompilerInterface1`, and we can use pattern matching to see which capability the compiler bridge implementation supports. This commit brings in those Java interfaces as well.

In any case, this commit brings back the old `java.io.File`-based methods, and locally I was able to get hello world from Dotty.
eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 12, 2020
@eed3si9n
Reluctantly restore compatibility of xsbti.*
8de29c5 
Fixes sbt#779

As it stands, compiler-interface and compiler bridge implementation are of internal concern of Zinc implementation. We _should_ be able to remove method or change the signatures. The word "interface" here is between Scalac and Zinc internal, not to the world.

In reality, the situation is more complicated because we have Dotty compiler out there that is bound to a specific version of compiler-interface. So when I released sbt 1.4.0-M1 this resulted in NoSuchMethodErrors:

```
[error] ## Exception when compiling 1 sources to /private/tmp/hello-dotty/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
....
[error] Caused by: java.lang.NoSuchMethodError: xsbti.compile.SingleOutput.getOutputDirectory()Ljava/io/File;
[error]   at xsbt.CachedCompilerImpl.<init>(CachedCompilerImpl.java:35)
```

To smooth things out, one approach we've discussed is to create a separate compiler-interface (in a different package) that is less dependent on Zinc specifics. Related to that, in sbt#661 I've created Java interface for `CompilerInterface1`, and we can use pattern matching to see which capability the compiler bridge implementation supports. This commit brings in those Java interfaces as well.

In any case, this commit brings back the old `java.io.File`-based methods, and locally I was able to get hello world from Dotty.
eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 14, 2020
@eed3si9n
Reluctantly restore compatibility of xsbti.*
b4df9a3 
Fixes sbt#779

As it stands, compiler-interface and compiler bridge implementation are of internal concern of Zinc implementation. We _should_ be able to remove method or change the signatures. The word "interface" here is between Scalac and Zinc internal, not to the world.

In reality, the situation is more complicated because we have Dotty compiler out there that is bound to a specific version of compiler-interface. So when I released sbt 1.4.0-M1 this resulted in NoSuchMethodErrors:

```
[error] ## Exception when compiling 1 sources to /private/tmp/hello-dotty/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
....
[error] Caused by: java.lang.NoSuchMethodError: xsbti.compile.SingleOutput.getOutputDirectory()Ljava/io/File;
[error]   at xsbt.CachedCompilerImpl.<init>(CachedCompilerImpl.java:35)
```

To smooth things out, one approach we've discussed is to create a separate compiler-interface (in a different package) that is less dependent on Zinc specifics. Related to that, in sbt#661 I've created Java interface for `CompilerInterface1`, and we can use pattern matching to see which capability the compiler bridge implementation supports. This commit brings in those Java interfaces as well.

In any case, this commit brings back the old `java.io.File`-based methods, and locally I was able to get hello world from Dotty.
@eed3si9n eed3si9n reopened this Jul 25, 2020
@eed3si9n
Copy link
Member

compile works, but doc seems to be broken still

[error] java.lang.NoSuchMethodException: xsbt.ScaladocInterface.run([Ljava.io.File;, [Ljava.lang.String;, xsbti.Logger, xsbti.Reporter)
[error] 	at java.lang.Class.getMethod(Class.java:1786)
[error] 	at sbt.internal.inc.AnalyzingCompiler.invoke(AnalyzingCompiler.scala:251)
[error] 	at sbt.internal.inc.AnalyzingCompiler.doc(AnalyzingCompiler.scala:154)
[error] 	at sbt.internal.inc.AnalyzingCompiler.doc(AnalyzingCompiler.scala:126)
[error] 	at sbt.Doc$.$anonfun$scaladoc$1(Doc.scala:52)
[error] 	at sbt.Doc$.$anonfun$scaladoc$1$adapted(Doc.scala:40)

@eed3si9n
Copy link
Member

I need to restore https://github.com/sbt/zinc/blob/v1.3.0/internal/compiler-bridge/src/main/scala/xsbt/ScaladocInterface.scala

class ScaladocInterface {
  def run(args: Array[String], log: Logger, delegate: xsbti.Reporter) =
    (new Runner(args, log, delegate)).run
}

eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 27, 2020
@eed3si9n
Fix doc task
fa75ec7 
Ref sbt#779
@eed3si9n eed3si9n mentioned this issue Jul 27, 2020
Merged
eed3si9n added a commit to eed3si9n/zinc that referenced this issue Jul 27, 2020
@eed3si9n
Fix doc task
efd0c3f 
Ref sbt#779
lrytz pushed a commit to lrytz/scala that referenced this issue Jul 13, 2023
@eed3si9n
Reluctantly restore compatibility of xsbti.*
e7f3542 
Fixes sbt/zinc#779

As it stands, compiler-interface and compiler bridge implementation are of internal concern of Zinc implementation. We _should_ be able to remove method or change the signatures. The word "interface" here is between Scalac and Zinc internal, not to the world.

In reality, the situation is more complicated because we have Dotty compiler out there that is bound to a specific version of compiler-interface. So when I released sbt 1.4.0-M1 this resulted in NoSuchMethodErrors:

```
[error] ## Exception when compiling 1 sources to /private/tmp/hello-dotty/target/scala-0.24/classes
[error] java.lang.RuntimeException: java.lang.reflect.InvocationTargetException
[error] xsbt.CompilerInterface.newCompiler(CompilerInterface.java:35)
....
[error] Caused by: java.lang.NoSuchMethodError: xsbti.compile.SingleOutput.getOutputDirectory()Ljava/io/File;
[error]   at xsbt.CachedCompilerImpl.<init>(CachedCompilerImpl.java:35)
```

To smooth things out, one approach we've discussed is to create a separate compiler-interface (in a different package) that is less dependent on Zinc specifics. Related to that, in sbt/zinc#661 I've created Java interface for `CompilerInterface1`, and we can use pattern matching to see which capability the compiler bridge implementation supports. This commit brings in those Java interfaces as well.

In any case, this commit brings back the old `java.io.File`-based methods, and locally I was able to get hello world from Dotty.

Rewritten from sbt/zinc@b4df9a3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
1.4.0
Development

Successfully merging a pull request may close this issue.

Reluctantly restore compatibility of xsbti.* eed3si9n/zinc
Fix Dotty doc task eed3si9n/zinc
3 participants
@eed3si9n @dwijnand @bishabosha