zinc failing

[dwijnand]

[zinc] [error] /home/jenkins/workspace/scala-2.11.x-integrate-community-build/target-0.9.5/project-builds/zinc-90d1013227f7306b3626e164e5d7fb65b57e5e4a/src/main/scala/com/typesafe/zinc/ClassLoaderCacheAccess.java:15:  cannot find symbol
[zinc] [error] symbol  : method withClassLoaderCache(sbt.classpath.ClassLoaderCache)
[zinc] [error] location: class sbt.compiler.AnalyzingCompiler
[zinc] [error] compiler.withClassLoaderCache
[zinc] [error] (compile:compileIncremental) javac returned nonzero exit code

in https://scala-ci.typesafe.com/view/scala-2.11.x/job/scala-2.11.x-integrate-community-build/516/console

This is due to this change: typesafehub/zinc#108

/cc @retronym @eed3si9n

[retronym]

Is this "just" a matter of bumping the version of SBT used in this community build?

Seems to be on

⚡ git describe 0b2f2ae5a8ab2b082b6e15b196d671a4c18cc9f2
v0.13.6-M1-31-g0b2f2ae5a

I added the scare quotes above in anticipation of finding this

  // change from https://github.com/sbt/sbt/pull/1509 broke building sbt with Scala 2.11
  // this problem is tracked in https://github.com/sbt/sbt/issues/1523
  // for now, we stick to fixed sha1 of sbt right before the merge of #1509
  sbt-ref                      : "sbt/sbt.git#0b2f2ae5a8ab2b082b6e15b196d671a4c18cc9f2"

[dwijnand]

Yeah I think you're right. But sbt/sbt#1523 is fixed with sbt/sbt#1531 which shipped in v0.13.6-RC1, so you shouldn't hit that issue.

[SethTisue]

I will resolve this by just freezing zinc at the last green commit. The 2.11 community build is basically unmaintained at this point — it's full of freezes and forks, and Scala 2.11.x development more generally is coming to an end. A likely future (and not very distant, either) is that we freeze all of the projects in the 2.11 community build, not just this one.

Note that zinc (either typesafehub/zinc or sbt/zinc) isn't currently in the 2.12/2.13 community builds at all.

I'm happy to help with including sbt and/or typesafehub/zinc and/or sbt/zinc and/or pieces thereof in the 2.12 community build if there's interest in that, when the time comes. See previous discussions at #264 and #290. At the time we said "to be revived at a later date".

@adriaanm and I discussed this a bit yesterday and he was concerned that we should probably have some kind of backstop against accidental breakage in the compiler interface. I've never worked in that area so I don't really have anything intelligent to say about what might be possible there.

[dwijnand]

@adriaanm and I discussed this a bit yesterday and he was concerned that we should probably have some kind of backstop against accidental breakage in the compiler interface. I've never worked in that area so I don't really have anything intelligent to say about what might be possible there.

Basically there could be ancient, deprecated APIs in the compiler/interpreter/scaladoc/etc that sbt still calls for whatever reason. And a well-intentioned person might remove them, breaking sbt.

Fortunately a few, an unknown-percentage-of-the-whole, are commented in the scala/scala repo: e.g https://github.com/scala/scala/search?l=Scala&p=6&q=sbt&type=Code&utf8=%E2%9C%93

[SethTisue]

Basically there could be ancient, deprecated APIs in the compiler/interpreter/scaladoc/etc that sbt still calls for whatever reason. And a well-intentioned person might remove them, breaking sbt.

Fortunately a few, an unknown-percentage-of-the-whole, are commented in the scala/scala repo: e.g https://github.com/scala/scala/search?l=Scala&p=6&q=sbt&type=Code&utf8=%E2%9C%93

so what would our strategy be for catching that? (is the community build the right venue?)

[dwijnand]

If the Scala team feels like it wants to change the API in the near future then we should definitely have all sbt 1 + modules up and running in the 2.12 and 2.13 community builds, probably using tags to start with, while we continue to faff about refactoring and breaking compatibilities between our own repos. Then the team would have to make a judgement call if they want to check it before merging a compiler API changing PR, or just merge and let the community build check it.

I guess technically one could tweak the sbt build so it had source dependency to the scala project, but I'm pre-coffee atm and I don't even want to think about the mind-blowing dogfooding/cyclical dependencies with such a setup :)

As an aside, do the community builds run nightly or on pushes (e.g PR merges) to the various stable branches (2.12.x/2.13.x/etc)?

[dwijnand]

@SethTisue Thinking more about this, while dealing with differences in the compiler API between versions in sbt/zinc, I think we're doing the work twice. The compiler is holding on to APIs "for sbt" while sbt is dealing with version differences in the compiler. I would have to go back and check what's going on in sbt 0.13, but I think some of those compiler APIs could be removed now.

---

Also, related, I think with a some coordination and effort between the Scala team and direct compiler API users (sbt, paradise, probably ensime, etc) I think both sides could reap benefits.

What I'm thinking is if we created a compiler-compat project (ala macro-compat), which was reviewed, blessed and co-maintained (or owned) by the compiler team, then the tools community would have a tool they could trust and request features or fixes, and the compiler team could refactor their API with more ease by putting the necessary shims in compiler-compat.

WDYT?

[fommil]

+1 we have so many *BackCompat mixins and implicit classes

[dwijnand]

@SethTisue Just did some comparing-and-contrasting between sbt/sbt incremental compiler sources and sbt/zinc. sbt/sbt (i.e sbt 0.13) is using the deprecated sources. In sbt/zinc there are 2.11+ sources and 2.10 sources, where the 2.11+ sources use the modern APIs (like enteringPhase instead of atPhase).

[SethTisue]

Dale — good thoughts, may I suggest you copy/paste into a new ticket and let's discuss further there? either here or scala-dev, whichever you think is more appropriate

[dwijnand]

scala/scala-dev#316