-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Broken repository name handling for build_settings and label_flag #10499
Comments
I'm a bit weak on repositories but I can at least triage. |
I can confirm that the problem is not just for
|
I'm having trouble prioritizing this at the moment. I'm going to refer to @juliexxia for better triage, and check if she has context that I don't. @juliexxia I don't understand the intersection of SBC and repositories very well. Feel free to own this or assign to someone else, but also feel free to assign back to me if there's no better obvious owner. I also appreciate input from anyone on the right impact priority. |
Let's consolidate these bugs into #11128. When that one is fixed, it if doesn't address this we can re-open this. |
This brings us home to the principle of "we always deal with canonicalized settings on the back end". Before this CL, this situation described in #10499 was still an issue. Some background: By design, the label-object map of starlark options in BuildOptions does not store starlark flags that are set to their default value (set either by never having been set, or explicitly set to the default value). This means before we do starlark transitions, we fill out the configuration with all the relevant default values so they're there if we need to read them. Before this CL, those editions to the map were being added in their given form, not there canonical form. This obviously caused issues when our transition logic tried to find these setting using their canonical form. This CL fixes that. The affected logic is ConfigurationResolver#addDefaultStarlarkOptions. Fixes #11128 PiperOrigin-RevId: 353923997
Wanted to express thanks for the detail of this issue report. Helped immensely with writing appropriate tests when writing this fix. Should be all fixed now, thanks for your patience. |
Description of the problem:
When using a
label_flag
that is defined in the main repository, it must be referred to as//:my_label_flag
on the command line and in transitions. Using@my_repo//:my_label_flag
will not work but will also not render any error message.If the same repository is used as an external, using by
@my_repo//:my_label_flag
is a must in the transitions as//:my_label_flag
always points to the main repository.Basically, the functionality is there, but the repository name handling is broken.
Expected behaviour
Transitions should not allow
build_setting
names without@
, either@//...
or@my_repo//...
should be used. Using//...
should render an error suggesting@my_repo//...
or@//...
, apart from when using the built in//command_line_option:...
.Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Now run
Remove
@sub
from sub/rules.bzl and you will getWhat operating system are you running Bazel on?
Linux
What's the output of
bazel info release
?release 2.0.0
Have you found anything relevant by searching the web?
Nothing found when searching for
label_flag
on GitHub issues: https://github.com/bazelbuild/bazel/issues?utf8=%E2%9C%93&q=is%3Aissue+label_flagRelates to bazel-dicsuss platforms, build_settings, transitions and features.
The example above is loosely based on https://github.com/bazelbuild/bazel/blob/master/src/test/shell/integration/starlark_configurations_test.sh.
The text was updated successfully, but these errors were encountered: