-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed instrumented.jar and scalacheck.jar location #102
Conversation
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. |
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
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
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