| commit | a3a4cf8c486d1d27e72d9e595c9d718efb21071a | [log] [tgz] |
|---|---|---|
| author | Googler <gregce@google.com> | Fri Oct 07 11:34:58 2022 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri Oct 07 11:36:10 2022 -0700 |
| tree | 68ae291512118c1965e0e72c4806b3aa8e51596d | |
| parent | 1e16a975c16204be4a7b5d4bb69522564763640c [diff] |
Adjust semantics for config_setting visibility migration. Today, config_setting_visibility is completely ignored. This also means for select() -> alias -> config_setting, the alias visibility is ignored. We'll migrate to full visibility checking in two steps: 1) Turn on --incompatible_enforce_config_setting_visibility. This turns on visibility checking but defaults config_setting visibility to public. This only causes depot failures for config_settings that are explicitly set otherwise, which we can clean up. 2) Turn on --incompatible_config_setting_private_default_visibility: this defaults config_setting visibility to private, which is standard visibility semantics. This will break more of the depot (i.e. any config_setting in a package that doesn't change its default visibility). We'll clean that up too. This change fixes a small issue with aliases. The intention of step 1 is that we allow config_settings that aren't explicitly visibility-restricted. But that would fail for a select() -> alias -> config_setting_with_default_visibility. Visibility checking independently checks the select() -> alias edge, which has the usual private default. This change skips that edge entirely and directly compares the select() against config_setting_with_default_visibility. We don't want to ultimately skip alias visibility checking. But we can get that working at step 2. As it stands now, at step 0, this is already skipped. So this change isn't a regression. It just helps smooth migration. For https://github.com/bazelbuild/bazel/issues/12932 and https://github.com/bazelbuild/bazel/issues/12933. PiperOrigin-RevId: 479631810 Change-Id: I8b77f62bb1584cc74d182995afa19fe70a8d4875
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
