Duplicate of sbt/zinc#227?

Alternatively could you provide, please, a minimal-but-complete reproduction? For instance sbt version, scala version, scala options, the test, etc. Following our ISSUE_TEMPLATE, ideally 😀.

Duplicate of sbt/zinc#227?

That one looks a particular side-effect of "does not track dependencies introduced by inlining" related with singleton types and final vals being always inlined by the type checker. This is something wider: you simply cannot trust the incremental compiler at all when using the 2.12 optimizer.

Alternatively could you provide, please, a minimal-but-complete reproduction? (...)

There you go, not just that but a dedicated repo:

• https://github.com/ohnosequences/sbt4125/blob/c3169097b485e742a721af4a58150ee9c8329dbb/README.md

Copying here the relevant portion of the link above; see ohnosequences/sbt4125 for more

steps

Open a shell and

git checkout "x=1"

Now run sbt on a different shell and do ~test. Once it runs for the first time,

git checkout "x=2"

Take a look at the test passing, and the definitions of x and y.

Problem

Incremental compilation when used together with the optimizer generates incorrect bytecode: modifications in methods/vals are not propagated to wherever they are being inlined.

Expectation

The incremental compiler should not ever generate incorrect bytecode.

Version

sbt 1.1.0 most likely previous ones too.

@eparejatobes Thanks for the report and reproduction.

I wasn't able to follow the instruction exactly:

$ git checkout "x=1"
error: pathspec 'x=1' did not match any file(s) known to git.

but I got the gist of what's going on from manually changing:

  @inline
  def x: Int = 1

to

  @inline
  def x: Int = 2

I wasn't able to follow the instruction exactly: (...)

My fault, forgot to push the tags; it should work now.

but I got the gist of what's going on (...)

yes, that's it. I can understand that fixing this would involve considerable work in zinc; I think then that there should be a way (however hackish) of disabling incremental compilation. Note that (as this example shows) I could perfectly publish bytecode wildly different from what the source should generate.

It can't be too difficult to invalidate everything whenever the flag is present, and show a warning saying "oh snap. you have inline flag on. we can't handle this."

I've reported also to sbt/zinc#537