[cormacrelf]

This essentially implements https://bazel.build/concepts/visibility#load-visibility.

Differences:

1. Buck2's starlark allows top level if/else in bzl files. Very minor
2. We support visibility(["//pkg:"]) but not visibility(["//pkg"]), matching the rest of buck2 visibility

Since no Buck2 code in existence uses visibility() as it didn't exist until now, and the default when omitted is equivalent to visibility("public"), we just enforce visibility by default. You can turn it off if you need to with [buck2] check_load_visibility = false.

Idea from #1287 (comment)

Note on package vs directory semantics

pkg
├── BUCK
├── defs.bzl
├── sub
│   └── defs.bzl
└── subpackage
    └── BUCK

• Package semantics: visibility(["//pkg:"]) is visible from pkg/defs.bzl AND pkg/sub/defs.bzl but NOT pkg/subpackage/.... This is what bazel does.
• Directory semantics: visibility(["//pkg:"]) is visible from pkg/defs.bzl BUT NOT any subdirectories or subpackages thereof. You would have to write //pkg/... which would include pkg/subpackage/BUCK subpackages. To include both //pkg and //pkg/sub, write both.

The original version of my code compared the cell paths' directories, not packages (dir trees rooted by BUCK files) -- this I was not attached to, but it matched how we write load()s. In bazel if you have pkg/BUILD and no other build files, you have load("//pkg:sub/defs.bzl", "my_rule") whereas we have load("//pkg/sub:defs.bzl", "my_rule"). Unfortunately combined with point (2) it can be a bit confusing because //pkg: is a target pattern rooted in pkg/BUCK and doesn't match //pkg/sub:*.bzl visually. So I'm not 100% sure what the best path is. Maybe if we wanted to match bazel's package visibility semantics we could add support for bazel's load syntax as well, which is in fact a literal one line change from FileName->ForwardRelativePath in an import parser? Not the biggest deal.

It makes more sense to me to be package based rather than directory. If you have a module of bzl code you can put some in a subdirectory called private/, write visibility("private") at the top of each, and then import those from a public interface. If directory-based, we would require you to write visibility("//pkg/...") in that very common scenario, "private" would be much less useful and this feature would be worse. In fact yeah, I think we should use package-based

Package-based will require some fancier dice keys so as not to be slower. I added some commits on the end that change this to package semantics and hopefully improve the perf of owner() and other similar queries.

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D128510197. (Because this pull request was imported automatically, there will not be any future comments.)