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
Locate the classes directory in zinc in order to relativize classnames #7853
Locate the classes directory in zinc in order to relativize classnames #7853
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM sans the nits.
Happy to see the nits fixed in a follow-up, as well.
) yield { | ||
// strongly hold the classNames, and transform them to ensure that they are unlinked from | ||
// the remainder of the analysis | ||
val classNames = analysis.relations.srcProd.reverseMap.keys.toList.toSet.map( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to assume that this long chain worked before :)
Feel free to ask for review again if I shouldn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, that's... relatively trustworthy.
val analysisDefinesClass = | ||
for ( | ||
abstractAnalysis <- getAnalysis(classpathEntry); | ||
analysis = abstractAnalysis.asInstanceOf[Analysis]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this always correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, in practice.
abstractAnalysis <- getAnalysis(classpathEntry); | ||
analysis = abstractAnalysis.asInstanceOf[Analysis]; | ||
compilation <- analysis.compilations.allCompilations.headOption; | ||
singleOutput <- compilation.getOutput.getSingleOutput.asScala; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this getSingleOutput
always single? I think so because we're only asking for the analysis of one file, but still I want to make sure.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea, this is effectively a dead API in zinc.
new ClassNamesDefinesClass(classNames) | ||
}.getOrElse { | ||
// If we have analysis with a valid Compilation, use the classnames it refers to. | ||
val analysisDefinesClass = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be worth annotating this with a type, it took me a while to determine that this for comprehension was single-element (an Option
) and not an iterator.
Problem
As described in #7850:
zinc
currently makes assumptions about directory layouts that aren't valid when it is being invoked viarsc
.Solution
Rather than attempting to recognize patterns, get the output directory of the compile to use for relativization.
Result
A followup PR will be able to confirm that
dep-usage.jvm
works underrsc
.