Always check $config_dependencies visibility at use#19139
Always check $config_dependencies visibility at use#19139fmeum wants to merge 1 commit intobazelbuild:masterfrom
$config_dependencies visibility at use#19139Conversation
All dependencies for `select` expressions are collected in an implicit `$config_dependencies` attribute. Even with `--incompatible_visibility_private_attributes_at_definition`, visibility for this attribute is now checked relative to the use rather than the definition of the rule.
|
@gregestren I got the results of a downstream run with this flag flipped and it looks promising. Do you think I could attempt to flip it for Bazel 7? |
|
@brandjon what's the story for @fmeum this seems useful to me but I don't have much on-the-ground perspective. Are you finding real failures addressed by this? I pinged @brandjon since he's done a lot of work on clarifying visibility checking, including definition vs. use. |
| "config_setting(", | ||
| " name = 'my_setting',", | ||
| " values = {'cpu': 'does_not_matter'},", | ||
| " visibility = ['//:__pkg__'],", |
There was a problem hiding this comment.
It does, the visibility check is bypassed with --noincompatible_config_setting_private_default_visibility, which means that this issue has only been around since the flip of --incompatible_config_setting_private_default_visibility pre Bazel 6.
There was a problem hiding this comment.
Wait, isn't that still off by default?
Or is this the connection?
There was a problem hiding this comment.
Yes, that is the connection, the issue goes away with --noincompatible_enforce_config_setting_visibility. Without the explicit visibility on the config_setting, the test added in this PR passes without the changes to the production code.
I do. From my perspective as a ruleset author, the current behavior is pretty unintuitive and effectively forces all tools used by rules to be publicly visible, even when those tools are considered internal. Examples include rules_go and rules_jvm_external. Since all tools in public rulesets need to be visible globally due to the current behavior, I would consider the risk of undetected breakages to be minimal. |
All dependencies for `select` expressions are collected in an implicit `$config_dependencies` attribute. Even with `--incompatible_visibility_private_attributes_at_definition`, visibility for this attribute is now checked relative to the use rather than the definition of the rule. Fixes bazelbuild#19126 Closes bazelbuild#19139. PiperOrigin-RevId: 553830083 Change-Id: Ic4af0f5ad9a0c627c973cd5ce88dd1e1bf51474e
All dependencies for `select` expressions are collected in an implicit `$config_dependencies` attribute. Even with `--incompatible_visibility_private_attributes_at_definition`, visibility for this attribute is now checked relative to the use rather than the definition of the rule. Fixes bazelbuild#19126 Closes bazelbuild#19139. PiperOrigin-RevId: 553830083 Change-Id: Ic4af0f5ad9a0c627c973cd5ce88dd1e1bf51474e
All dependencies for `select` expressions are collected in an implicit `$config_dependencies` attribute. Even with `--incompatible_visibility_private_attributes_at_definition`, visibility for this attribute is now checked relative to the use rather than the definition of the rule. Fixes bazelbuild#19126 Closes bazelbuild#19139. PiperOrigin-RevId: 553830083 Change-Id: Ic4af0f5ad9a0c627c973cd5ce88dd1e1bf51474e
All dependencies for `select` expressions are collected in an implicit `$config_dependencies` attribute. Even with `--incompatible_visibility_private_attributes_at_definition`, visibility for this attribute is now checked relative to the use rather than the definition of the rule. Fixes #19126 Closes #19139. PiperOrigin-RevId: 553830083 Change-Id: Ic4af0f5ad9a0c627c973cd5ce88dd1e1bf51474e Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
All dependencies for
selectexpressions are collected in an implicit$config_dependenciesattribute. Even with--incompatible_visibility_private_attributes_at_definition, visibility for this attribute is now checked relative to the use rather than the definition of the rule.Fixes #19126