Changes to Contraband json files don't trigger invalidation of source that uses the generated *.java code

[smarter]

I have no idea if this is a bug in sbt, zinc, contraband, or a combination of all the above:

steps

1. Edit type.json, add a random field to any class, (for example add: { "name": "quack", "type": "String" }, to Projection
2. Run compile, notice that java files are generated from the json file as expected and they are recompiled

problem

but notice also that you don't get any compilation error, even though you just changed the constructor of Projection which is used in internal/compiler-bridge/src/main/scala/xsbt/ExtractAPI.scala for example.

expectation

internal/compiler-bridge/src/main/scala/xsbt/ExtractAPI.scala etc should no longer compile.

notes

3. Do ;clean;compile, notice that everything still compiles, very weird!
4. Stop sbt. Start sbt again, do ;clean;compile, finally you get error messages!

Any clue what's going on? /cc @eed3si9n

[jvican]

Is this issue reproducible in Zinc 1.0 or 0.13? If it's in 0.13.x it may make more sense to file a ticket there 😄.

Regarding the issue, this looks indeed weird. The third point is baffling... Is this how the universe is set up to work?

[smarter]

Well this issue happens when trying to work on zinc itself, so I think the zinc bugtracker is appropriate until we figure out what causes the issue (it might be a pecularity of the zinc build.sbt for example).

[jvican]

Closed by accident. Let's see what's making this happen.

[jvican]

Note to myself: this is a bug of our current setup and only affects people hacking on Zinc. It is not a bug of Zinc 1.0 per se.

[smarter]

While working on #287 I've run into the same issue when changing AnalysisCallback.java so this doesn't seem to be specifc to contraband-generated java files, but happen with any kind of java files. As before, stopping and restarting sbt is the only way to get things to work.

[jvican]

@smarter I've run into this lately when making lots of changes to contraband.

@eed3si9n Please, can you have a look at this? I'm losing way too much time cleaning, removing all dirs and exiting sbt to make changes in the API. If you help me here, I'll be able to make progress much much faster 😄.

[dwijnand]

Related to sbt/contraband#75.

[eed3si9n]

I always thought "hey this works for me" until I read it more carefully.
Guillaume is actually talking about transitive invalidation caused by the change in signature of generated Java code. There's some change that Contraband plugin is not coded correctly somehow, but it feels more like a bug in sbt 0.13's incremental compiler.

[eed3si9n]

I'm now more certain it's sbt issue because it won't happen if I comment out:

    exportJars := true,

so exportJars is making other subprojects treat compilerInterface as if it's a "library" dependency, which in a way is true, but even if that's the case it should invalidate.
I'm curious if Zinc inherits this bug from sbt/sbt, and if I should now move and/or open issue under sbt/sbt as well.

[smarter]

@eed3si9n Does this only happen when compiling with Scala 2.12? If so I bet this is scala/bug#10295

[eed3si9n]

Interesting. You might be right. Using Scala 2.11.8 it did detect the Java signature change in the JAR:

> compile
...
[info] Compiling 10 Scala sources to /xxx/zinc/internal/zinc-apiinfo/target/scala-2.11/classes...
[error] /xxx/zinc/internal/compiler-bridge/src/main/scala/xsbt/ExtractAPI.scala:192: not enough arguments for constructor Projection: (x$1: xsbti.api.Type, x$2: String, x$3: String)xsbti.api.Projection.
[error] Unspecified value parameter x$3.
[error]     else new xsbti.api.Projection(processType(in, pre), simpleName(sym))
[error]          ^
[error] one error found

[smarter]

If -YdisableFlatCpCaching fixes it for 2.12, could you comment on scala/bug#10295 ? I think it's a pretty serious issue but it hasn't gotten any attention yet.