Upgrade our build to sbt 1.5.4. #4516
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This allows the JVM bytecode generator not to crash on those definitions.
This allows the JVM bytecode generator not to crash when compiling the scalalib.
If the base directory does not exist yet at the time the setting is constructed, the URI did not contain a trailing '/'. That could cause spurious full recompilation during the *second* run after a 'clean'. We now ensure that there is always a trailing '/'.
593546a to
0640632
Compare
Now that we got rid of the idiosynchrasies of our build that prevented us from using the JVM back-end, and hence sbt's integration with the compiler, we can enable them. We configure the incremental compiler to recompile everything or nothing on the javalib and scalalib projects, because the incremental compiler can still get confused about those.
This way, we make sure that all our scripted tests keep using sbt 1.2.8 (except the two tests using 1.5.4 for Scala 3).
30a3f64 to
2e225d8
Compare
gzm0
approved these changes
Jun 21, 2021
As a side effect, this solves the issue that testSuite2_*/test was
always logging debug messages. Now they are only displayed with the
`-v` option. This will dramatically reduce the disk space used by
logs on the CI servers.
The sbt plugin is still compiled against sbt 1.0.0 artifacts, and
the scripted tests are still executed against sbt 1.2.8. Hopefully
that is enough to ensure that we do not break sbt 1.{2,3,4}.x
users.
sjrd
commented
Jun 22, 2021
Comment on lines
208
to
230
| def typeRefVar(field: String, typeRef: NonArrayTypeRef)( | ||
| implicit moduleContext: ModuleContext, globalKnowledge: GlobalKnowledge, | ||
| pos: Position): Tree = { | ||
| /* Explicitly bringing `PrimRefScope` and `ClassScope` as local implicit | ||
| * vals should not be necessary, and used not to be there. When upgrading | ||
| * to sbt 1.5.4 from 1.2.8, compilation started failing because of missing | ||
| * implicit `Scope[PrimRef]` and `Scope[ClassName]` in this method, in | ||
| * *some* environments (depending on machine, OS, JDK version, in or out | ||
| * IDE, regular compile versus Scaladoc, etc., perhaps the phase of the | ||
| * moon, for all I could tell). It is not even clear that the sbt version | ||
| * is actually relevant. | ||
| * Regardless, the explicit vals reliably fix the issue. | ||
| */ | ||
| typeRef match { | ||
| case primRef: PrimRef => | ||
| implicit val primRefScope: Scope[PrimRef] = Scope.PrimRefScope | ||
| globalVar(field, primRef) | ||
|
|
||
| case ClassRef(className) => | ||
| implicit val classScope: Scope[ClassName] = Scope.ClassScope | ||
| globalVar(field, className) | ||
| } | ||
| } |
There was a problem hiding this comment.
@gzm0 I had to add the above changes to make the CI pass. There were errors like
[error] linker/shared/src/main/scala/org/scalajs/linker/backend/emitter/VarGen.scala:213:18: could not find implicit value for evidence parameter of type VarGen.this.Scope[org.scalajs.ir.Types.PrimRef]
[error] Error occurred in an application involving default arguments.
[error] globalVar(field, primRef)
[error] ^
[error] linker/shared/src/main/scala/org/scalajs/linker/backend/emitter/VarGen.scala:216:18: could not find implicit value for evidence parameter of type VarGen.this.Scope[org.scalajs.ir.Names.ClassName]
[error] Error occurred in an application involving default arguments.
[error] globalVar(field, className)
[error] ^
[error] two errors found
[error] Scaladoc generation failed
When trying to investigate, I also observed the same error on my local Windows machine, but only in the IDE. That was without regenerating the build, so supposedly the IDE was still using the config generated through sbt 1.2.8.
Is that OK for you?
There was a problem hiding this comment.
If it's the only thing we can do :-/ In the past for me, the incremental compiler failed on this specific thing if there were other errors in the same file. IIRC, cleaning helped.
Are we 100% sure the CI environment is clean?
There was a problem hiding this comment.
We do git clean -fdx && rm -rf partest/fetchedSources/ at the beginning of each CI job, so yes, it's pretty clear that it is clean.
There was a problem hiding this comment.
Also linker$v/compile succeeds, during the same CI run, before linker$v/compile:doc fails, so ...
gzm0
approved these changes
Jun 23, 2021
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Naively upgrading to sbt >= 1.3.x caused lots of spurious recompilations. (See past attempt in #4360.) After some investigation, it was caused by our
ExternalCompile.scalasetup, which overridescompilebut notcompileIncremental. OverridingcompileIncrementalproved virtually impossible. Instead, I looked into getting rid ofExperimentalCompilealtogether, which led me to several changes that were necessary to play nicely with the JVM back-end and the incremental compiler.