Do not munge visibility
attribute for targets created by symbolic macros
#23855
Labels
P1
I'll work on this now. (Assignee required)
team-Loading-API
BUILD file and macro processing: labels, package(), visibility, glob
type: bug
@bazel-io flag 8.0.0
This potentially blocks Bazel 8.0 because without fixing this, the
bazel query
-introspectedvisibility
value of targets created in Symbolic Macros is misleading/inconsistent.Currently, for targets created within a symbolic macro, the
visibility
attribute that gets stored on the target is munged to include the instantiating location. This contrasts with the rawvisibility
attribute that gets stored on targets not in symbolic macros, which matches whatever thevisibility =
argument passed to the instantiation site was.We can't munge for targets not in symbolic macros, because it would likely imply a memory regression for the overwhelming majority of the build, and it would change the introspected
visibility
value for those targets relative to what is seen today innative.existing_rules
andbazel query
. But at the same time, the munging for targets in symbolic macros is also problematic, both due to the inconsistency and because tooling that reads the introspected values might expect them to match the source text of a BUILD file.The proper solution is probably to be consistent by
visibility
for any target$actual_visibility
, to hold the munged value (regardless of whether the target is inside a symbolic macro), that can be introspected inbazel query
but not innative.existing_rules
. This attribute should not be materialized in normal builds.Symbolic macros themselves also have a
visibility
attribute, and it must always be munged (as it currently is) so that the implementation function sees the correct value for itsvisibility
parameter. But if we expose symbolic macro attributes viabazel query
in the future, we may very well want to avoid the munging to preserve consistency with rules. Note that munging happens at every level of a chain of symbolic macro calls, and the raw visibility for one macro is the munged visibility for its caller.Implementing this probably just requires a little work in
RuleFactory
andConfiguredTargetFactory
, plus updating some code comments that explain the outdated invariant. I'm not completely sure what the precedent is for syntheticquery
-only attributes.The text was updated successfully, but these errors were encountered: