-
Notifications
You must be signed in to change notification settings - Fork 4.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
Fix visibility check at definition for aspects #19442
Conversation
0e2def4
to
c7289ce
Compare
@mai93 @comius was right in #19141 (comment), the aspect case of I think that visibility for an implicit attribute of an aspect should be checked relative to that aspect's definition. I have implemented this in this PR and added test cases. The new tests uncovered the interesting edge case of which attribute wins if two aspects define attributes with the same name. In the spirit of @mai93's commit 93ad589, I would argue that the outer aspect should see its own attribute or it might risk being broken by being applied to an aspect with an attribute of an incompatible type. Is flipping that behavior around something we could do? If not, could we do that for implicit attributes only? Picking up an implicit attribute from a lower aspect instead of the own one seems just wrong. |
Thanks @fmeum! I also think the main aspect should get its dependencies from its own attributes not from its underlying aspects. I need to run internal tests for this part to verify that there is nothing depending on the old behaviour that needs to be updated first. |
src/test/java/com/google/devtools/build/lib/analysis/AspectTest.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/analysis/CommonPrerequisiteValidator.java
Outdated
Show resolved
Hide resolved
@mai93 Thanks for the feedback. I will separate out the change to aspect ordering. I identified another place in which this ordering would probably need to be changed, but it doesn't seem to be covered by tests: #19449 |
4f9f0c6
to
f5f0838
Compare
4126a9a
to
46f5235
Compare
46f5235
to
22c8921
Compare
@mai93 I set the test blocked on #19449 to ignored as you suggested in #19449 (comment). |
if (!RuleContext.isVisible(implicitDefinition, prerequisite.getConfiguredTarget())) { | ||
handleVisibilityConflict(context, prerequisite, implicitDefinition); | ||
} | ||
} | ||
} | ||
|
||
private static boolean forStarlarkRuleOrAspect(RuleContext.Builder context) { | ||
Aspect currentAspect = context.getMainAspect(); | ||
if (currentAspect != null && currentAspect.getAspectClass() instanceof StarlarkAspectClass) { |
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 missed this in the first review but if the aspect is native, this needs to return False
and not fallback to the rule type.
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.
Good catch, fixed. Also renamed the local variable to mainAspect
.
e3d7e1a
to
81ee3b3
Compare
src/main/java/com/google/devtools/build/lib/analysis/CommonPrerequisiteValidator.java
Outdated
Show resolved
Hide resolved
src/main/java/com/google/devtools/build/lib/analysis/CommonPrerequisiteValidator.java
Outdated
Show resolved
Hide resolved
// Only verify visibility of implicit dependencies of the current aspect. Implicit | ||
// dependencies of other aspects as well as the rule itself are checked when they are | ||
// evaluated. | ||
return; |
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.
Readability: The return
here breaks the encapsulation of the else block. You can't add any code after the block and assume it's correct.
Possible solution is to invert if (!mainAspect.getDefinition().getAttributes().containsKey(attrName)) {
and move the block if (!RuleContext.isVisible...
inside after setting implicitDefinition
.
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 wasn't entirely sure what you meant with "move the block ... inside". I left it outside without duplicating it, please let me know what you think.
src/test/java/com/google/devtools/build/lib/analysis/VisibilityTest.java
Show resolved
Hide resolved
src/test/java/com/google/devtools/build/lib/analysis/VisibilityTest.java
Outdated
Show resolved
Hide resolved
With `--incompatible_visibility_private_attributes_at_definition`, the visibility of aspects (and aspects on aspects) into their implicit dependencies is now checked relative to the aspect's, not the rule's definition.
81ee3b3
to
2ed46a7
Compare
src/test/java/com/google/devtools/build/lib/analysis/VisibilityTest.java
Show resolved
Hide resolved
This is ready for reimport. @iancha1992 |
With `--incompatible_visibility_private_attributes_at_definition`, the visibility of aspects (and aspects on aspects) into their implicit dependencies is now checked relative to the aspect's, not the rule's definition. This requires ensuring the precedence of aspect on aspect attributes over those of the underlying aspect in `DependencyResolutionHelper`, which was hinted at by a comment but not realized. Closes #19442. PiperOrigin-RevId: 567333681 Change-Id: I167c45fea8535e0f35c0298ca1cb9f845c9fe2d2 (cherry picked from commit 7a537ca)
With `--incompatible_visibility_private_attributes_at_definition`, the visibility of aspects (and aspects on aspects) into their implicit dependencies is now checked relative to the aspect's, not the rule's definition. This requires ensuring the precedence of aspect on aspect attributes over those of the underlying aspect in `DependencyResolutionHelper`, which was hinted at by a comment but not realized. Closes #19442. PiperOrigin-RevId: 567333681 Change-Id: I167c45fea8535e0f35c0298ca1cb9f845c9fe2d2 (cherry picked from commit 7a537ca)
With
--incompatible_visibility_private_attributes_at_definition
, the visibility of aspects (and aspects on aspects) into their implicit dependencies is now checked relative to the aspect's, not the rule's definition.This requires ensuring the precedence of aspect on aspect attributes over those of the underlying aspect in
DependencyResolutionHelper
, which was hinted at by a comment but not realized.