bazel query rdeps fails in //external because //:dummy target doesn't exist

[jschaf]

Description of the problem / feature request:

Using rdeps against the //external package fails because Bazel tries to resolve the android_sdk_for_testing bind rule to //:dummy using the local repository instead of Bazel's root BUILD.

# src/main/java/com/google/devtools/build/lib/bazel/rules/android/android.WORKSPACE
bind(
    name = "android_sdk_for_testing",
    actual = "//:dummy",
)

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

# WORKSPACE
workspace(name = "bazel_dummy_target")

bazel query 'rdeps(//external:*, //external:bazel_tools, 3)'

ERROR: /DEFAULT.WORKSPACE:25:1: no such target '//:dummy': target 'dummy' 
  not declared in package '' defined by <BAZEL>/BUILD.bazel 
  and referenced by '//external:android_sdk_for_testing'

ERROR: /DEFAULT.WORKSPACE:25:1: no such target '//:dummy': target 'dummy' 
  not declared in package '' defined by <BAZEL>/BUILD.bazel 
  and referenced by '//external:android_sdk_for_testing'

What operating system are you running Bazel on?

MacOS

What's the output of bazel info release?

release 0.24.1

Any other information, logs, or outputs that you want to share?

A workaround is to add the dummy target in my local repo. It seems like Bazel should use it's own dummy target.

filegroup(
    name = "dummy",
    visibility = ["//visibility:public"],
)

[comius]

I'm surprised that depending on jdk.BUILD only throws an error on query, but not already when the target is defined. It looks like there is another bug, that allows repo rules to depend on un-exported files from other packages.

[linzhp]

@jschaf @ahumesky I believe this can be closed.

@comius I agree. Many repos exploited this bug. Here is another example, in which //:third_party/zlib.BUILD is not exported:

https://github.com/protocolbuffers/protobuf/blob/eb8976a56d3f596ada8562dcff27724fb3f3625c/protobuf_deps.bzl#L31-L37

[linzhp]

@comius created #15185 to follow up.