Scripted test value-class-underlying is not really passing
#442
Labels
Comments
smarter
added a commit
to smarter/zinc
that referenced
this issue
Oct 24, 2017
Quoting from 1e7e99e: 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 This was true until aca8dfa where we started giving unique names to constructors. This broke the value-class-underlying type but this wasn't noticed because the test was broken in the same commit (and has now been fixed in the previous commit in this PR).
|
Hah, this happens because I'm using the name |
smarter
added a commit
to smarter/zinc
that referenced
this issue
Oct 24, 2017
Quoting from 1e7e99e: 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 This was true until aca8dfa where we started giving unique names to constructors. This broke the value-class-underlying type but this wasn't noticed because the test was broken in the same commit (and has now been fixed in the previous commit in this PR).
smarter
added a commit
to smarter/zinc
that referenced
this issue
Oct 24, 2017
Quoting from 1e7e99e: 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 This was true until aca8dfa where we started giving unique names to constructors. This broke the value-class-underlying type but this wasn't noticed because the test was broken in the same commit (and has now been fixed in the previous commit in this PR).
smarter
added a commit
to smarter/zinc
that referenced
this issue
Nov 8, 2017
Quoting from 1e7e99e: 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 This was true until aca8dfa where we started giving unique names to constructors. This broke the value-class-underlying type but this wasn't noticed because the test was broken in the same commit (and has now been fixed in the previous commit in this PR).
smarter
added a commit
to smarter/zinc
that referenced
this issue
Nov 8, 2017
Quoting from 1e7e99e: 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 This was true until aca8dfa where we started giving unique names to constructors. This broke the value-class-underlying type but this wasn't noticed because the test was broken in the same commit (and has now been fixed in the previous commit in this PR).
dwijnand
added a commit
that referenced
this issue
Nov 8, 2017
Fix #442: Name hash of value class should include underlying type
|
Fixed in #444. |
dwijnand
added a commit
to dwijnand/zinc
that referenced
this issue
Nov 22, 2017
* 1.0.x: (25 commits) Add yourkit acknoledgement in the README Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 Fix source-dependencies/sealed Import statement no longer needed Move mima exclusions to its own file ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).
dwijnand
added a commit
to dwijnand/zinc
that referenced
this issue
Nov 23, 2017
* 1.0.x: (28 commits) Split compiler bridge tests to another subproject Implement compiler bridge for 2.13.0-M2 Add yourkit acknoledgement in the README "sbt '++ 2.13.0-M2!' compile" does not work with sbt 1.0.0 Add header to cached hashing spec Add headers to missing files Fix sbt#332: Add sbt-header back to the build Update sbt-scalafmt to 1.12 Make classpath hashing more lightweight Fix sbt#442: Name hash of value class should include underlying type source-dependencies/value-class-underlying: fix test Ignore null in generic lambda tparams Improve and make scripted parallel Fix sbt#436: Remove annoying log4j scripted exception Fix sbt#127: Use `unexpanded` name instead of `name` Add pending test case for issue/127 source-dependencies / patMat-scope workaround Fixes undercompilation on inheritance on same source Add real reproduction case for sbt#417 Add trait-trait-212 for Scala 2.12.3 ... Conflicts: internal/zinc-apiinfo/src/main/scala/sbt/internal/inc/ClassToAPI.scala project/build.properties zinc/src/main/scala/sbt/internal/inc/MixedAnalyzingCompiler.scala The ClassToAPI conflict is due to: * sbt#393 (a 1.x PR), conflicting with * sbt#446 (a 1.0.x PR). The build.properties conflict is due to different PRs bumping sbt.version from 1.0.0 to 1.0.2 to 1.0.3. (sbt#413, sbt#418, sbt#453). The MixedAnalyzingCompiler conflict is due to: * sbt#427 (a 1.x PR), conflicting with * sbt#452 (a 1.0.x PR).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
While working on the dotty compiler bridge, I noticed that the test
value-class-underlyingwas not passing after upgrading to zinc 1.0. It turns out that the test has been slightly modified in #288, and the changes were not reflected in Dotty's test suite: https://github.com/sbt/zinc/pull/288/files#diff-5023f5eef484bafd395d49f4a09f817bR4If this line is removed, then the scripted test fails at the second
run. If we revert #288, the test passes again./cc @smarter
Scripted log
The text was updated successfully, but these errors were encountered: