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

0.13.11 regression: incremental compiler: IndexOutOfBoundsException in ExtractAPI #2497

Closed
SethTisue opened this issue Mar 3, 2016 · 8 comments
Closed

0.13.11 regression: incremental compiler: IndexOutOfBoundsException in ExtractAPI #2497

SethTisue opened this issue Mar 3, 2016 · 8 comments
Labels
area/incremental_compiler Bug

Comments

@SethTisue
Copy link
Member

this turned up in the Scala community build at e.g. https://scala-ci.typesafe.com/job/scala-2.11.x-jdk8-integrate-community-build/166/consoleFull, in @lihaoyi's fastparse project.

possible interested parties: @adriaanm, @Duhemm?

how to reproduce: hub clone lihaoyi/fastparse; cd fastparse; edit project/build.properties and change 0.13.9 to 0.13.11; sbt sbt fastparseJVM/test

resulting stack trace:

[info] Compiling 9 Scala sources to /Users/tisue/fastparse/fastparse/jvm/target/scala-2.11/test-classes...
java.lang.IndexOutOfBoundsException: 0
    at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:65)
    at scala.collection.immutable.List.apply(List.scala:84)
    at xsbt.ExtractAPI.makeParameter$1(ExtractAPI.scala:295)
    at xsbt.ExtractAPI.xsbt$ExtractAPI$$parameterS$1(ExtractAPI.scala:286)
    at xsbt.ExtractAPI$$anonfun$parameterList$1$1.apply(ExtractAPI.scala:225)
    at xsbt.ExtractAPI$$anonfun$parameterList$1$1.apply(ExtractAPI.scala:225)
    at scala.collection.immutable.List.map(List.scala:273)
    at xsbt.ExtractAPI.parameterList$1(ExtractAPI.scala:225)
    at xsbt.ExtractAPI.build$1(ExtractAPI.scala:246)
    at xsbt.ExtractAPI.defDef(ExtractAPI.scala:303)
    at xsbt.ExtractAPI.xsbt$ExtractAPI$$definition(ExtractAPI.scala:419)
    at xsbt.ExtractAPI$$anonfun$xsbt$ExtractAPI$$processDefinitions$1.apply(ExtractAPI.scala:400)
    at xsbt.ExtractAPI$$anonfun$xsbt$ExtractAPI$$processDefinitions$1.apply(ExtractAPI.scala:400)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:252)
    at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:252)
    at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
    at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)
    at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:252)
    at scala.collection.mutable.ArrayOps$ofRef.flatMap(ArrayOps.scala:186)
    at xsbt.ExtractAPI.xsbt$ExtractAPI$$processDefinitions(ExtractAPI.scala:400)
    at xsbt.ExtractAPI$$anonfun$mkStructure$3.apply(ExtractAPI.scala:397)
    at xsbt.ExtractAPI$$anonfun$mkStructure$3.apply(ExtractAPI.scala:397)
    at xsbt.Message$$anon$1.apply(Message.scala:7)
    at xsbti.SafeLazy$$anonfun$apply$1.apply(SafeLazy.scala:7)
    at xsbti.SafeLazy$Impl._t$lzycompute(SafeLazy.scala:18)
    at xsbti.SafeLazy$Impl._t(SafeLazy.scala:16)
    at xsbti.SafeLazy$Impl.get(SafeLazy.scala:22)
    at xsbt.ExtractAPI$$anonfun$forceStructures$1.apply(ExtractAPI.scala:144)
    at xsbt.ExtractAPI$$anonfun$forceStructures$1.apply(ExtractAPI.scala:144)
    at scala.collection.immutable.List.foreach(List.scala:381)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:144)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
    at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
    at xsbt.API$ApiPhase.processScalaUnit(API.scala:53)
    at xsbt.API$ApiPhase.processUnit(API.scala:38)
    at xsbt.API$ApiPhase.apply(API.scala:36)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply$mcV$sp(Global.scala:440)
    at scala.tools.nsc.Global$GlobalPhase.withCurrentUnit(Global.scala:431)
    at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:440)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:398)
    at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:398)
    at scala.collection.Iterator$class.foreach(Iterator.scala:742)
    at scala.collection.AbstractIterator.foreach(Iterator.scala:1194)
    at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:398)
    at xsbt.API$ApiPhase.run(API.scala:31)
    at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1501)
    at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1486)
    at scala.tools.nsc.Global$Run.compileSources(Global.scala:1481)
    at scala.tools.nsc.Global$Run.compile(Global.scala:1582)
    at xsbt.CachedCompiler0.run(CompilerInterface.scala:116)
    at xsbt.CachedCompiler0.run(CompilerInterface.scala:95)
    at xsbt.CompilerInterface.run(CompilerInterface.scala:26)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:101)
    at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:47)
    at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:41)
    at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply$mcV$sp(MixedAnalyzingCompiler.scala:50)
    at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply(MixedAnalyzingCompiler.scala:50)
    at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply(MixedAnalyzingCompiler.scala:50)
    at sbt.compiler.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:74)
    at sbt.compiler.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:49)
    at sbt.compiler.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:64)
    at sbt.compiler.IC$$anonfun$compileInternal$1.apply(IncrementalCompiler.scala:160)
    at sbt.compiler.IC$$anonfun$compileInternal$1.apply(IncrementalCompiler.scala:160)
    at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:66)
    at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:64)
    at sbt.inc.IncrementalCommon.cycle(IncrementalCommon.scala:32)
    at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:68)
    at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:67)
    at sbt.inc.Incremental$.manageClassfiles(Incremental.scala:95)
    at sbt.inc.Incremental$.compile(Incremental.scala:67)
    at sbt.inc.IncrementalCompile$.apply(Compile.scala:54)
    at sbt.compiler.IC$.compileInternal(IncrementalCompiler.scala:160)
    at sbt.compiler.IC$.incrementalCompile(IncrementalCompiler.scala:138)
    at sbt.Compiler$.compile(Compiler.scala:152)
    at sbt.Compiler$.compile(Compiler.scala:138)
    at sbt.Defaults$.sbt$Defaults$$compileIncrementalTaskImpl(Defaults.scala:860)
    at sbt.Defaults$$anonfun$compileIncrementalTask$1.apply(Defaults.scala:851)
    at sbt.Defaults$$anonfun$compileIncrementalTask$1.apply(Defaults.scala:849)
        [...]
SethTisue added a commit to SethTisue/community-build that referenced this issue Mar 3, 2016
@SethTisue
build fastparse with an older sbt version for now
9488cb9 
because sbt/sbt#2497
@SethTisue SethTisue mentioned this issue Mar 3, 2016
Merged
@Duhemm
Copy link
Contributor

Duhemm commented Mar 4, 2016

Reverting commit 49431eb fixes the issue... But this commit fixes another, bigger issue: #2411.

See #2418

@adriaanm
Copy link
Contributor

adriaanm commented Mar 4, 2016

Could it be because we're looking at erased types? Normally, varargs erase
to Seq, but maybe somehow some wires got crossed?

scala> :power
scala> class C { def foo(x: String*) = ??? }
scala> transformedType(typeOf[C].nonPrivateMember(TermName("foo")).info)
(x: Seq)Nothing

On Fri, Mar 4, 2016 at 11:30 AM, Martin Duhem notifications@github.com
wrote:

Reverting commit 49431eb
49431eb
fixes the issue... But this commit fixes another, bigger issue: #2411
#2411.

See #2418 #2418

—
Reply to this email directly or view it on GitHub
#2497 (comment).

@eed3si9n
Copy link
Member

/cc @gkossakowski

@gkossakowski
Copy link
Contributor

Have you guys considered a different approach of dealing with value classes that I mentioned before: #2261 (comment) ?

My solution would avoid phase travel that I think is both confusing and error-prone.

I believe this issue would go away simply because we would no longer need information at erasure.

@smarter smarter mentioned this issue Mar 29, 2016
Merged
smarter added a commit to smarter/zinc that referenced this issue Apr 9, 2016
@smarter
Simplify value class API handling and fix sbt/sbt#2497
ed60417 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to sbt#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that use a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/zinc that referenced this issue Apr 9, 2016
@smarter
Simplify value class API handling and fix sbt/sbt#2497
e1d6991 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to sbt#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that use a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.
gkossakowski added a commit to sbt/zinc that referenced this issue Apr 14, 2016
@gkossakowski
Merge pull request #95 from smarter/simplify/value-class
429a4e4 
 Simplify value class API handling and fix sbt/sbt#2497
@smarter
Copy link
Contributor

smarter commented Apr 14, 2016

Github decided to close this but this isn't actually fixed in sbt/sbt, just in sbt/zinc (sbt/zinc#95)

smarter added a commit to smarter/sbt that referenced this issue Apr 14, 2016
@smarter
Simplify value class API handling and fix sbt#2497
b706d4a 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
@smarter
Copy link
Contributor

smarter commented Apr 14, 2016

Backport of the fix to sbt 0.13: #2557

smarter added a commit to smarter/sbt that referenced this issue Apr 14, 2016
@smarter
Simplify value class API handling and fix sbt#2497
310610b 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 15, 2016
@smarter
Simplify value class API handling and fix sbt#2497
a5f2d2a 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 15, 2016
@smarter
Simplify value class API handling and fix sbt#2497
714c449 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 15, 2016
@smarter
Simplify value class API handling and fix sbt#2497
4c632b8 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 15, 2016
@smarter
Simplify value class API handling and fix sbt#2497
1bbe517 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 16, 2016
@smarter
Simplify value class API handling and fix sbt#2497
dd683ff 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 18, 2016
@smarter
Simplify value class API handling and fix sbt#2497
be55343 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 19, 2016
@smarter
Simplify value class API handling and fix sbt#2497
aee0fa2 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 20, 2016
@smarter
Simplify value class API handling and fix sbt#2497
be911bb 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
smarter added a commit to smarter/sbt that referenced this issue Apr 20, 2016
@smarter
Simplify value class API handling and fix sbt#2497
aab822c 
This is a backport of sbt/zinc#95

The previous approach to value class API (introduced by sbt#2261 and
refined by sbt#2413 and sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced
recompilations.
This is no longer necessary thanks to sbt#2523: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of `<init>` changes and since every class uses the name
`<init>`, we don't need to do anything special to trigger recompilations
either.
eed3si9n added a commit that referenced this issue May 4, 2016
@eed3si9n
Merge pull request #2557 from smarter/simplify/value-class
1880173 
[BPORT] Simplify value class API handling and fix #2497
@drdozer
Copy link

drdozer commented Jun 27, 2016

I think I'm hitting this. My stacktrace is:

java.lang.IndexOutOfBoundsException: 0
        at scala.collection.LinearSeqOptimized$class.apply(LinearSeqOptimized.scala:65)
        at scala.collection.immutable.List.apply(List.scala:84)
        at xsbt.ExtractAPI.makeParameter$1(ExtractAPI.scala:295)
        at xsbt.ExtractAPI.xsbt$ExtractAPI$$parameterS$1(ExtractAPI.scala:286)
        at xsbt.ExtractAPI$$anonfun$parameterList$1$1.apply(ExtractAPI.scala:225)
        at xsbt.ExtractAPI$$anonfun$parameterList$1$1.apply(ExtractAPI.scala:225)
        at scala.collection.immutable.List.map(List.scala:273)
        at xsbt.ExtractAPI.parameterList$1(ExtractAPI.scala:225)
        at xsbt.ExtractAPI.build$1(ExtractAPI.scala:246)
        at xsbt.ExtractAPI.defDef(ExtractAPI.scala:303)
        at xsbt.ExtractAPI.xsbt$ExtractAPI$$definition(ExtractAPI.scala:419)
        at xsbt.ExtractAPI$$anonfun$xsbt$ExtractAPI$$processDefinitions$1.apply(ExtractAPI.scala:400)
        at xsbt.ExtractAPI$$anonfun$xsbt$ExtractAPI$$processDefinitions$1.apply(ExtractAPI.scala:400)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
        at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:241)
        at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
        at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)
        at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:241)
        at scala.collection.mutable.ArrayOps$ofRef.flatMap(ArrayOps.scala:186)
        at xsbt.ExtractAPI.xsbt$ExtractAPI$$processDefinitions(ExtractAPI.scala:400)
        at xsbt.ExtractAPI$$anonfun$mkStructure$3.apply(ExtractAPI.scala:397)
        at xsbt.ExtractAPI$$anonfun$mkStructure$3.apply(ExtractAPI.scala:397)
        at xsbt.Message$$anon$1.apply(Message.scala:7)
        at xsbti.SafeLazy$$anonfun$apply$1.apply(SafeLazy.scala:7)
        at xsbti.SafeLazy$Impl._t$lzycompute(SafeLazy.scala:18)
        at xsbti.SafeLazy$Impl._t(SafeLazy.scala:16)
        at xsbti.SafeLazy$Impl.get(SafeLazy.scala:22)
        at xsbt.ExtractAPI$$anonfun$forceStructures$1.apply(ExtractAPI.scala:144)
        at xsbt.ExtractAPI$$anonfun$forceStructures$1.apply(ExtractAPI.scala:144)
        at scala.collection.immutable.List.foreach(List.scala:381)
        at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:144)
        at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
        at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
        at xsbt.ExtractAPI.forceStructures(ExtractAPI.scala:145)
        at xsbt.API$ApiPhase.processScalaUnit(API.scala:53)
        at xsbt.API$ApiPhase.processUnit(API.scala:38)
        at xsbt.API$ApiPhase.apply(API.scala:36)
        at scala.tools.nsc.Global$GlobalPhase$$anonfun$applyPhase$1.apply$mcV$sp(Global.scala:440)
        at scala.tools.nsc.Global$GlobalPhase.withCurrentUnit(Global.scala:431)
        at scala.tools.nsc.Global$GlobalPhase.applyPhase(Global.scala:440)
        at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:398)
        at scala.tools.nsc.Global$GlobalPhase$$anonfun$run$1.apply(Global.scala:398)
        at scala.collection.Iterator$class.foreach(Iterator.scala:893)
        at scala.collection.AbstractIterator.foreach(Iterator.scala:1336)
        at scala.tools.nsc.Global$GlobalPhase.run(Global.scala:398)
        at xsbt.API$ApiPhase.run(API.scala:31)
        at scala.tools.nsc.Global$Run.compileUnitsInternal(Global.scala:1501)
        at scala.tools.nsc.Global$Run.compileUnits(Global.scala:1486)
        at scala.tools.nsc.Global$Run.compileSources(Global.scala:1481)
        at scala.tools.nsc.Global$Run.compile(Global.scala:1582)
        at xsbt.CachedCompiler0.run(CompilerInterface.scala:116)
        at xsbt.CachedCompiler0.run(CompilerInterface.scala:95)
        at xsbt.CompilerInterface.run(CompilerInterface.scala:26)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at sbt.compiler.AnalyzingCompiler.call(AnalyzingCompiler.scala:101)
        at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:47)
        at sbt.compiler.AnalyzingCompiler.compile(AnalyzingCompiler.scala:41)
        at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply$mcV$sp(MixedAnalyzingCompiler.scala:50)
        at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply(MixedAnalyzingCompiler.scala:50)
        at sbt.compiler.MixedAnalyzingCompiler$$anonfun$compileScala$1$1.apply(MixedAnalyzingCompiler.scala:50)
        at sbt.compiler.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:74)
        at sbt.compiler.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:49)
        at sbt.compiler.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:64)
        at sbt.compiler.IC$$anonfun$compileInternal$1.apply(IncrementalCompiler.scala:160)
        at sbt.compiler.IC$$anonfun$compileInternal$1.apply(IncrementalCompiler.scala:160)
        at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:66)
        at sbt.inc.IncrementalCompile$$anonfun$doCompile$1.apply(Compile.scala:64)
        at sbt.inc.IncrementalCommon.cycle(IncrementalCommon.scala:32)
        at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:68)
        at sbt.inc.Incremental$$anonfun$1.apply(Incremental.scala:67)
        at sbt.inc.Incremental$.manageClassfiles(Incremental.scala:95)
        at sbt.inc.Incremental$.compile(Incremental.scala:67)
        at sbt.inc.IncrementalCompile$.apply(Compile.scala:54)
        at sbt.compiler.IC$.compileInternal(IncrementalCompiler.scala:160)
        at sbt.compiler.IC$.incrementalCompile(IncrementalCompiler.scala:138)
        at sbt.Compiler$.compile(Compiler.scala:152)
        at sbt.Compiler$.compile(Compiler.scala:138)
        at sbt.Defaults$.sbt$Defaults$$compileIncrementalTaskImpl(Defaults.scala:860)
        at sbt.Defaults$$anonfun$compileIncrementalTask$1.apply(Defaults.scala:851)
        at sbt.Defaults$$anonfun$compileIncrementalTask$1.apply(Defaults.scala:849)
        at scala.Function1$$anonfun$compose$1.apply(Function1.scala:47)
        at sbt.$tilde$greater$$anonfun$$u2219$1.apply(TypeFunctions.scala:40)
        at sbt.std.Transform$$anon$4.work(System.scala:63)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
        at sbt.Execute$$anonfun$submit$1$$anonfun$apply$1.apply(Execute.scala:228)
        at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
        at sbt.Execute.work(Execute.scala:237)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
        at sbt.Execute$$anonfun$submit$1.apply(Execute.scala:228)
        at sbt.ConcurrentRestrictions$$anon$4$$anonfun$1.apply(ConcurrentRestrictions.scala:159)
        at sbt.CompletionService$$anon$2.call(CompletionService.scala:28)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

@eed3si9n
Copy link
Member

@drdozer Could you try the nightly 0.13.12-20160610-062406 and see if that solves your issue?

@SkyWriter SkyWriter mentioned this issue Mar 17, 2017
Closed
eed3si9n pushed a commit to eed3si9n/scala that referenced this issue May 14, 2019
@smarter
Simplify value class API handling and fix sbt/sbt#2497
9d9d0a7 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.
lrytz pushed a commit to lrytz/scala that referenced this issue Nov 5, 2019
@smarter
Simplify value class API handling and fix sbt/sbt#2497
f1d3170 
The previous approach to value class API (introduced by sbt/sbt#2261 and
refined by sbt/sbt#2413 and sbt/sbt#2414) was to store both unerased and
erased signatures so that changes to value classes forced recompilations.
This is no longer necessary thanks to scala#87: if a class type is
used, then it becomes a dependency of the current class and its name is
part of the used names of the current class. Since the name hash of a
class changes if it stops or start extending AnyVal, this is enough to
force recompilation of anything that uses a value class type. If the
underlying type of a value class change, its name hash doesn't change,
but the name hash of <init> change and since every class uses the name
<init>, we don't need to do anything special to trigger recompilations
either.

Rewritten from sbt/zinc@1e7e99e
@amnaredo amnaredo mentioned this issue Jul 25, 2021
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/incremental_compiler Bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@gkossakowski @smarter @adriaanm @SethTisue @eed3si9n @drdozer @Duhemm