bazelbuild / bazelbuild/bazel

RuleContext.checkSrcsSamePackage has no callers (dead code)

Open
#30,290 1 comment 0 reactions 0 assignees View on GitHub
P3 team-Rules-CPP type: bug
Dominant language
Java
Stars
25.8k
Forks
4.6k
Avg merge
2d 16h
Merged PRs (30d)
72

Description

## Summary

`RuleContext.checkSrcsSamePackage(boolean onlyWarn)` is a public method that validates cross-package `srcs` references and emits either an `attributeWarning` or `attributeError`. As of the current tree, **nothing calls it**.

## Location

`src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java` (around line 1300):

```java
/**
* Check that all targets that were specified as sources are from the same package as this rule.
* Output a warning or an error for every target that is imported from a different package.
*/
public void checkSrcsSamePackage(boolean onlyWarn) {
...
if (onlyWarn) {
attributeWarning("srcs", message);
} else {
attributeError("srcs", message);
}
}
```

A repo-wide search finds only the method definition — no call sites in production code, tests, or Starlark rules.

## History

The method previously had callers, but they were removed over time:

1. **2019** — Removed from `CcLibrary` and `CcBinary` intentionally (closes #10121, RELNOTES: "Remove 'please do not import' warning for cc rules"). Commit `5d4e855fd0`.
2. **Later** — Removed along with native rule implementations when rules migrated out of Bazel core:
- `JavaBinary` (commit `f551289281`)
- native `java_library` (commit `1192addd99`)
- Android rules (`android_local_test` base class, etc.)

After those removals, the helper was left behind with no remaining callers.

## Impact

- The cross-package `srcs` diagnostic path is unreachable.
- `attributeWarning("srcs", ...)` from this method can never fire.
- Maintainers may assume this check is active when it is not.

## Suggested next steps

Please pick one (or clarify intent):

1. **Remove the dead code** if cross-package `srcs` warnings/errors are no longer desired.
2. **Re-wire the check** centrally (e.g. in prerequisite validation) if the policy is still useful — possibly as a warning, matching the old `onlyWarn=true` behavior.
3. **Document explicitly** if the method is kept intentionally for external/custom rule authors (though it is currently unused even in-tree).

Happy to send a PR once direction is confirmed.

Contributor guide

Open the contributing guide

Research direction

Start with checkSrcsSamePackage in src/main/java/com/google/devtools/build/lib/analysis/RuleContext.java and verify the reported repo-wide search for callers. Review the linked history and wait for a decision on removal, rewiring, or documentation before changing anything. Done means implementing the chosen direction and updating relevant tests or documentation.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
build-system
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.