bazelbuild
Unexported (non-global) provider symbols are allowed despite documentation specification
Description of the bug:
https://bazel.build/rules/lib/globals/bzl#provider describes provider() to:
Defines a provider symbol. The result of this function must be stored in a global value.
The use of "must" creates the expectation that such symbols would be disallowed, but there doesn't appear to be enforcement of this behavior.
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
$ cat defs.bzl
def _make_local_provider():
return struct(inner = provider(fields = {"foo": ""}))
def impl(ctx): return None
r = rule(impl, attrs = {})
def m(name):
print(_make_local_provider().inner(foo = "bar"))
r(name = name)
$ cat BUILD
load(":defs.bzl", "m")
m(name = "t")
$ bazelisk build :t
DEBUG: .. unexported_providers/defs.bzl:8:10: struct(foo = "bar")
INFO: Analyzed target //:t (1 packages loaded, 1 target configured).
INFO: Found 1 target...
Target //:t up-to-date (nothing to build)
INFO: Elapsed time: 0.126s, Critical Path: 0.00s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action
$ bazelisk version
Bazelisk version: v1.10.1
Build label: 7.3.2
Build target: @@//src/main/java/com/google/devtools/build/lib/bazel:BazelServer
Build time: Tue Oct 1 17:46:05 2024 (1727804765)
Build timestamp: 1727804765
Build timestamp as int: 1727804765
The inner provider() was not stored in a global value, but the build still succeeded.
Which operating system are you running Bazel on?
linux
What is the output of bazel info release?
7.3.2
If bazel info release returns development version or (@non-git), tell us how you built Bazel.
No response
What's the output of git remote get-url origin; git rev-parse HEAD ?
No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
The documentation string was introduced in https://github.com/bazelbuild/bazel/commit/3ebfe2450b66467b7c91b5da0f289b50686cb9bc
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
Interesting point! I added this in commit 3ebfe2450b66467b7c91b5da0f289b50686cb9bc to address a straightforward means to crash the build tool during the analysis phase. The "must be a global variable" enforcement happens when you try to use the unexported provider in a rule implementation function, ie. ctx.attr.some_input[_make_local_provider().inner] should produce a proper error message (and not a crash).
I think it is probably a lot of work to enforce the "must be a global variable" earlier than the analysis phase, as I think that would require a static analysis flowing backward from every provider() call.
Would a rephrasing of the docs help? I'd be happy to accept a patch adding this nuance to the docs. eg. "The result of this function must be stored in a global value in order to be used in a rule or aspect implementation function."
