Skip to content
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

Merged

Conversation

stuhood
Copy link
Sponsor Member

@stuhood stuhood commented Jun 5, 2019

Problem

As described in #7850: zinc currently makes assumptions about directory layouts that aren't valid when it is being invoked via rsc.

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 under rsc.

@stuhood
Copy link
Sponsor Member Author

stuhood commented Jun 5, 2019

Saw both #7853 and #7856, but otherwise green.

Copy link
Contributor

@blorente blorente left a 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(
Copy link
Contributor

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.

Copy link
Sponsor Member Author

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];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this always correct?

Copy link
Sponsor Member Author

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;
Copy link
Contributor

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.

Copy link
Sponsor Member Author

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 =
Copy link
Contributor

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.

@stuhood stuhood merged commit e9936fb into pantsbuild:master Jun 5, 2019
@stuhood stuhood deleted the stuhood/analysis-path-hardcoding-fix branch June 5, 2019 18:18
stuhood added a commit that referenced this pull request Jun 6, 2019
### Problem

We need to release #7853, which fixes #7850.

### Solution

Bump to the version built in #7853, and modify a test to confirm that it is fixed.
stuhood added a commit that referenced this pull request Jun 7, 2019
### Problem

We need to release #7853, which fixes #7850.

### Solution

Bump to the version built in #7853, and modify a test to confirm that it is fixed.
@illicitonion illicitonion removed this from the 1.17.x milestone Jul 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants