Fix #441 under-invalidation: hash PACKAGE_GROUP targets and follow visibility edges

[tinder-maxwellelliott]

What

Fixes the under-invalidation (false-negative) half of #441, pinned by the reproducer in #442: a change to a package_group's packages list — which can flip a downstream consumer from building to failing visibility analysis — was completely invisible to bazel-diff, because BazelQueryService.toBazelTarget dropped every query target whose Discriminator was not RULE / SOURCE_FILE / GENERATED_FILE.

How

Two parts, because hashing the group alone is not enough — visibility labels are nodep labels, so bazel query never lists them in rule_input, and the group's digest would be stranded with no edge to the rules it gates:

1. Lower PACKAGE_GROUP query targets to synthetic rules (BazelQueryService.packageGroupToTarget): rule class package_group, the packages allow-list as a hashed STRING_LIST attribute, and includes as rule_inputs (so editing a nested group propagates to every group that includes it). This mirrors how bzlmod repos are already lowered to synthetic //external:* rules, and lets package_groups ride the existing hashing pipeline unchanged.
2. Follow visibility edges in RuleHasher: package_group labels found in a rule's visibility attribute are followed as dep edges, so the gated rule — and transitively its dependents — re-hash when the group changes. The special //visibility:public|private forms and __pkg__/__subpackages__ package specs name no target and are filtered out (BazelRule.visibilityPackageGroupLabels); a label whose group is outside the queried graph is skipped, matching its pre-fix invisibility. The edge is suppressed when visibility is in --ignoredRuleHashingAttributes.

Hash stability

Existing workspaces without package_groups referenced in visibility produce byte-for-byte identical hashes: only resolvable package_group labels contribute bytes, and //visibility:*-only fixtures are unaffected (verified by the untouched expectations of every other E2E test).

Tests

• The Add reproducer for #441: package_group change not detected as impacted (false negative) #442 reproducer is flipped into testPackageGroupChangeImpactsConsumers_regressionForIssue441, asserting the exact impacted set: //lib:consumers, //lib:thing, //lib:thing.txt, //consumer:use_thing, //consumer:use_thing.txt — the group, the rule it gates, and its transitive dependents, where before the set was empty.
• New unit tests for visibilityPackageGroupLabels (special-form filtering, dedupe + sort determinism) and isPackageGroup.
• Full bazel test //... is green locally except 4 pre-existing cquery/Maven E2E failures that also fail on master in this environment (sandboxed rules_jvm_external resolution), unrelated to this change.

Out of scope

• The over-invalidation half of Distinguish macro source changes from changes to Bazel's loaded package state #441 (print-only macro edits invalidating generated rules) — still a design/policy question.
• exports_files(..., visibility = ...): source-file targets don't yet follow package_group edges; same class of gap, left as a follow-up.
• ENVIRONMENT_GROUP targets remain dropped (near-dead feature; same lowering technique would apply if ever needed).

Refs #441, #442.

🤖 Generated with Claude Code