| commit | 36d170fe8451c3c768f70f35155de8df1b3e5a7e | [log] [tgz] |
|---|---|---|
| author | Googler <brandjon@google.com> | Tue Aug 20 10:22:35 2024 -0700 |
| committer | Copybara-Service <copybara-worker@google.com> | Tue Aug 20 10:23:56 2024 -0700 |
| tree | b2a72fb092765ed2bb2faa256f878cc69aa94c9d | |
| parent | 90aea317aa17bc34f905f39412f1dbbd3c6d60ca [diff] |
For symbolic macros, implicitly append the current location to target's visibility attr The design of Macro-Aware Visibility says that a target is visible to the locations given in its visibility attribute, plus the location where the target is declared (its BUILD file, or the package of the .bzl where the current symbolic macro was exported). This CL automatically concatenates the declaration location into the materialized visibility attribute of targets that are declared inside symbolic macros. Since we're munging the visibility attribute, this is a loading-time effect, and the result can be seen in `bazel query` output (or in our unit tests, with Target#getVisibility). When we add a visibility attribute to symbolic macros, they will have the same behavior, with the result that the visibility argument seen in macro implementation functions will include the caller's location. Targets that are not declared within a symbolic macro are unaffected, and will continue to show visibility attribute values that do not necessarily include their package explicitly. A subsequent change will work around this behavioral difference between targets in macros and out of macros, by adding the declaration location for the latter at analysis time, in the visibility provider. We went with this hybrid approach in order to avoid a massive and immediate change to all targets' visibilities. It's not clear whether we need to change this in the future for consistency. Changes: - Add a map in Package, from target name to its innermost declaring macro. Add a couple TODOs for future optimization. Add a corresponding utility function Target#getDeclaringMacro. - Add Package#visibilityWithCurrentMacro(), a utility function for munging a visibility attribute value to append the location of the currently executing symbolic macro's definition. Apply this to rule declarations in RuleFactory, and also to exports_files in StarlarkNativeModule. - Clean up RuleFactory#generatorAttributesForMacros by moving attribute map reconstruction into the caller where it can be handled alongside visibility. Clarify comments. - Add TODO comment about reserved macro attr names. - Add visibility attr tests to PackageFactoryTest. Also rename a helper method and add another helper method for unrelated symbolic macro tests. Work toward #19922. PiperOrigin-RevId: 665419955 Change-Id: I98ae1acdfbed3662ae00624d663dac1d35b9a8ec
{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
