bazel-contrib / bazel-contrib/buildtools
buildifier rewrite BUILD targets "@abc//:abc" incorrectly.
- Dominant language
- Go
- Stars
- 1.2k
- Forks
- 470
- Avg merge
- 2d 22h
- Merged PRs (30d)
- 13
Description
Our project uses the re2 library. Presently this is named "com_google_re2" in our workspace, but I'm trying to rename the repository to follow more common conventions.
This rename gives me a BUILD.bazel file with the following:
```
cc_library(
name = ...
deps = [
...
"@re2//:re2"
]
)
```
After running buildifier on it the deps are rewritten to:
```
deps = [
...
"@re2",
...
]
```
This rewrite causes bazel build errors like:
```
ERROR: git/tensorstore/tensorstore/util/BUILD?l=694:23: no such package '@@re2//': The repository '@@re2' could not be resolved: '@@re2' is not a repository rule and referenced by '//tensorstore/util:unit'
```
I believe that this is incorrect; buildifier should leave this dep as-is since in `@re2//:re2`, the repository is `re2`, the package is the empty string, and the target is `re2`.
This behavior is tested in build/testdata/019.build.golden
// Second, it removes redundant target qualifiers, turning labels like
// "//third_party/m4:m4" into "//third_party/m4" as well as ones like
// "@foo//:foo" into "@foo".
https://github.com/bazelbuild/buildtools/blob/f37c35dc3237698f02b9123d39000a31e91db9c9/build/rewrite.go#L291
Contributor guide
Research direction
Start in build/rewrite.go around the label-rewriting logic referenced in the issue, then inspect the expected behavior in build/testdata/019.build.golden. Verify that repository-qualified labels such as "@re2//:re2" retain the target when the repository and target names match, while existing redundant target simplifications remain covered by the golden test.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 72/100