Visibility attributes in sub-workspace for top-level workspace targets breaks `bazel build //...`

Description of the problem / feature request:

Given a workspace top_level_workspace and a sub-workspace third_party_lib:

If a visibility declaration to a target is added to third_party_lib to grant visibility to targets in top_level_workspace, bazel build //... in top_level_workspace will fail; only bazel build @top_level_workspace//... works.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Minimal repro workspace: visibility_bug_minimal_repro.zip

In the following workspace:

WORKSPACE

workspace(name = "top_level_workspace")

local_repository(
    name = "third_party_lib",
    path = "third_party_lib",
)

//foo/BUILD.bazel

filegroup(
    name = "some_app",
    srcs = [
        "local_file.txt",
        "@third_party_lib//:third_party_target",
    ],
)

//third_party_lib/BUILD.bazel

filegroup(
    name = "third_party_target",
    srcs = ["target.txt"],
    visibility = [
        "@top_level_workspace//foo:__pkg__",
    ],
)

• bazel build @top_level_workspace//foo/... succeeds

• bazel build //foo/... fails:

  ERROR: /home/bminor/dev/bazel_workspace_bug/foo/BUILD.bazel:1:1: in filegroup rule //foo:some_app: target '@third_party_lib//:third_party_target' is not visible from target '//foo:some_app'. Check the visibility declaration of the former target if you think the dependency is legitimate
  ERROR: Analysis of target '//foo:some_app' failed; build aborted: Analysis of target '//foo:some_app' failed; build aborted
  

Since the current working directory is in @top_level_workspace, I would expect that these two commands are equivalent; shouldn't //foo/... resolve to this workspace unambiguously? It's definitely inconvenient to lose the ability to do bazel build //... due to this.

What operating system are you running Bazel on?

Fedora Workstation 31

What's the output of bazel info release?

release 1.2.1

Have you found anything relevant by searching the web?

No, but this issue is a bit ambiguous to search for. Please feel free to dupe if this is already known.

[laszlocsomor]

Thanks for reporting.

This is a consequence of Bazel treating @// and @top_level_workspace// differently.
The --incompatible_remap_main_repo flag merges the two and solves this issue.

I cannot tell though when --incompatible_remap_main_repo will be enabled.

/cc @aehlig

[laszlocsomor]

FYI, we plan to release Bazel 2.0.0 this month and to enable --incompatible_remap_main_repo by default.

[laurentlb]

Sounds like the issue is now fixed.