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.