Fixed instrumented.jar and scalacheck.jar location #102
Conversation
This file contains 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
Depending on the file order in the directory, PathSettings.srcSpecLib could end up as "instrumented.jar.desired.sha1" instead of "instrumented.jar" which would cause all the specialized tests to fail. The same goes for scalacheck.jar
|
I just realized that lib could be a directory also... Fixing up |
|
Does this fix specialized tests? If so, I'm forever grateful to you! Also, I'd like some classes in how to track down this kind of problem. :-) |
|
Yes, this fixes those tests, but currently it finds the first file or directory named "instrumented_.jar". I figured it would match better the original behavior if it would look for a directory named "instrumented_" or a file named "instrumented*.jar". I think, giving priority to the directory would also make sense. So, this is what I'm gonna do now. To be honest, I can't remember how I found this bug. :) |
|
I just realized that the original didn't accept directories, only files, just like this fix, so I'm reopening. |
szeiger
pushed a commit
to szeiger/scala
that referenced
this pull request
Mar 20, 2018
eed3si9n
pushed a commit
to eed3si9n/scala
that referenced
this pull request
May 14, 2019
Previously, the main class detection was handled by https://github.com/sbt/zinc/blob/1.0/internal/zinc-apiinfo/src/main/scala/xsbt/api/Discovery.scala which looks for a main method with the correct signature in the extracted API. This is imperfect because it relies on ExtractAPI dealiasing types (because Discovery will look for a main method with a parameter type of `java.lang.String` and won't recognize `scala.Predef.String`), dealiasing means that the extracted API looses information and thus can lead to undercompilation. This commit partially fixes this by adding a new callback to AnalysisCallback: void mainClass(File sourceFile, String className) that is used to explicitly register main entry points. This way, tools do not need to interpret the extracted API, this is much better since it makes it easier for zinc to evolve the API representation. This commit does not actually changes ExtractAPI to not dealias, this can be done in a later PR. Note that there is another usecase for xsbt.api.Discovery that this PR does not replace: discovering tests. This is more complicated because different test frameworks have different ways to discover tests. For more information, grep for "Fingerprint" in https://github.com/sbt/sbt and https://github.com/sbt/junit-interface
lrytz
pushed a commit
to lrytz/scala
that referenced
this pull request
Nov 5, 2019
Previously, the main class detection was handled by https://github.com/sbt/zinc/blob/1.0/internal/zinc-apiinfo/src/main/scala/xsbt/api/Discovery.scala which looks for a main method with the correct signature in the extracted API. This is imperfect because it relies on ExtractAPI dealiasing types (because Discovery will look for a main method with a parameter type of `java.lang.String` and won't recognize `scala.Predef.String`), dealiasing means that the extracted API looses information and thus can lead to undercompilation. This commit partially fixes this by adding a new callback to AnalysisCallback: void mainClass(File sourceFile, String className) that is used to explicitly register main entry points. This way, tools do not need to interpret the extracted API, this is much better since it makes it easier for zinc to evolve the API representation. This commit does not actually changes ExtractAPI to not dealias, this can be done in a later PR. Note that there is another usecase for xsbt.api.Discovery that this PR does not replace: discovering tests. This is more complicated because different test frameworks have different ways to discover tests. For more information, grep for "Fingerprint" in https://github.com/sbt/sbt and https://github.com/sbt/junit-interface Rewritten from sbt/zinc@f10c53c
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.
Depending on the file order in the directory, PathSettings.srcSpecLib
could end up as "instrumented.jar.desired.sha1" instead of "instrumented.jar"
which would cause all the specialized tests to fail.
The same goes for scalacheck.jar