incompatible_no_implicit_file_export: implicitly exported files have private visibility

[aehlig]

If the flag --incompatible_no_implicit_file_export is enabled, files that are implicitly exported because they are mentioned in the BUILD have private visibility regardless of the default visibility of the package.

Migration: add an explicit exports_files for all files that should be used outside the package they belong to.

Design document: https://github.com/bazelbuild/proposals/blob/master/designs/2019-10-24-file-visibility.md

[drigz]

This flag causes a build error in an empty workspace with Bazel 2.0:

$ echo > WORKSPACE
$ bazel build @bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:all_lcov_merger_lib --incompatible_no_implicit_file_export
ERROR: /path/to/bazel/cache/10d1bb0ae85cffec5f45c68b4660ed75/external/bazel_tools/tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator/BUILD:4:1: in java_import rule @bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:all_lcov_merger_lib: target '@remote_coverage_tools//:all_lcov_merger_tools_deploy.jar' is not visible from target '@bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:all_lcov_merger_lib'. Check the visibility declaration of the former target if you think the dependency is legitimate
ERROR: Analysis of target '@bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:all_lcov_merger_lib' failed; build aborted: Analysis of target '@bazel_tools//tools/test/CoverageOutputGenerator/java/com/google/devtools/coverageoutputgenerator:all_lcov_merger_lib' failed; build aborted

I've also seen this error referring to @remote_coverage_tools//:all_lcov_merger_tools_deploy.jar.

This causes our build to fail for reasons I don't fully understand. Do @remote_coverage_tools and @bazel_tools need to be fixed before we can try applying this flag to our repositories, or should we remove the dependency on the broken targets?

See also: bazelbuild/continuous-integration#887

[martis42]

This is labeled with breaking-change-5.0, which I interpret as the intention to flip this with Bazel 5.0.0.
The flag is however still inactive by default:
https://github.com/bazelbuild/bazel/blob/5.0.0/src/main/java/com/google/devtools/build/lib/packages/semantics/BuildLanguageOptions.java#L426

Please update the issue status.

[brandjon]

I'd be interested in possibly flipping this for Bazel 7.0.

Note that there appears to be a edge case bug in the current implementation. //foo:BUILD is always considered a source file target of //foo, even if this BUILD file does not contain a mention of its own label. Yet if //foo:BUILD does not appear in an exports_files declaration, it will inherit the package's default visibility (not private visibility), even if this flag is enabled. Seems to me the correct behavior is to apply the flag to :BUILD file targets as well.

[dws]

I tried turning this on in a repo that I'm working with and discovered (with Bazel 6.2.0):

target '@bazel_tools//tools/cpp:cc_toolchain_config_lib.bzl' is not visible

so it appears that tools/cpp/BUILD.tools in the Bazel sources needs to be fixed. It appears that tools/cpp/BUILD in the Bazel sources already has an exports_files(glob(["*.bzl"])) line, but this addition did not make it into the other BUILD.* files (even in the current master).

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

[fmeum]

@bazelbuild/triage not stale