Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Incompatible Target Skipping ignores visibility restrictions #16044

@philsc

Description

@philsc

Description of the bug:

With #14096, we're fixing a few usability issues with Incompatible Target Skipping. That is accomplished by moving the code to a much earlier stage of the analysis phase. Unfortunately, that means it runs before visibility is checked.

This is not inherently a problem as it doesn't allow you to bypass visibility restrictions for building code. Compatible targets still obey visibility restrictions. And incompatible targets cannot be built.

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

Create an incompatible target in package //a.

# a/BUILD
filegroup(
    name = "private_filegroup",
    visibility = ["//visibility:private"],
    srcs = [...],
)
filegroup(
    name = "private_incompatible_filegroup",
    visibility = ["//visibility:private"],
    target_compatible_with = ["@platforms//:incompatible"],
    srcs = [...],
)

Create a target that is either directly incompatible or indirectly incompatible in a different package that depends on one of the private targets.

# b/BUILD
filegroup(
    name = "directly_incompatible",
    srcs = [
        "//a:private_filegroup",
    ],
    target_compatible_with = ["@platforms//:incompatible"],
)
filegroup(
    name = "indirectly_incompatible",
    srcs = [
        "//a:private_incompatible_filegroup",
    ],
)

Neither //b:directly_incompatible nor //b:indirectly_incompatible will generate errors about visibility restrictions.

One possible course of action is to move the visibility checking earlier. #14096 (comment)

Which operating system are you running Bazel on?

x86_64 Debian 11

What is the output of bazel info release?

No response

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

This is cbe2532 but with #14096 merged in.

I'm filing the bug report preemptively.

What's the output of git remote get-url origin; git rev-parse master; git rev-parse HEAD ?

$ git remote get-url upstream; git rev-parse master; git rev-parse HEAD
https://github.com/bazelbuild/bazel
e860453a7be19cc557d02b4edec13819358945fe
21a5fd1b5e091d4fb26ba683bfb3ff31d2f16621

Have you found anything relevant by searching the web?

No response

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

The hope is to merge #14096 and separately work on this bug.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P3We're not considering working on this, but happy to review a PR. (No assignee)staleIssues or PRs that are stale (no activity for 30 days)team-Configurabilityplatforms, toolchains, cquery, select(), config transitionstype: bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions