-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Query language attr cannot filter on the name attribute. #278
Comments
@damienmg @laszlocsomor It seems to work for me with the current master branch. Running the command on the "Getting Started" example project gives:
Running the command on the bazel code base also seems to work
|
Filtering still doesn't work for me with 0.4.4:
|
@laszlocsomor I can reproduce the bug.Will look... Also, should |
They should be different. The first one lists input and output file targets along with rules, the second one should only list rules. |
It seems like a problem accessing the attribute value - it's always the empty string. While |
The name attribute gets special treatment in the codebase, in that it's not simply yet another attribute but stored in it's own field. Thus, every callside dealing with attributes needs to be aware of this special case and explicitly handle the name attribute. It's easy to see that this can lead to bugs. For example, querying for the name attribute is currently broken due the querying code not being aware of the special case [1]. Discussions with experienced bazel developers came to the conclusion that there is no need (anymore) to treat the name attribute specially and thus we decided it's best to remove the special treatment and handle the name attribute as any other attribute. This change removes the handling of name attributes and also adds a test case to verify that bug [1] is fixed. [1] bazelbuild/bazel#278 -- PiperOrigin-RevId: 147446345 MOS_MIGRATED_REVID=147446345
Repro:
bazel query 'attr("name", ".*", //...)'
Result:
an empty set.
Expected:
All rule target
The text was updated successfully, but these errors were encountered: