commit 66b64633e3ae1f9c5c0016c3ea30be006796e6d3
author brandjon <brandjon@google.com> Thu Dec 17 14:11:32 2020 -0800
committer Copybara-Service <copybara-worker@google.com> Thu Dec 17 14:12:44 2020 -0800
tree 23011b492f916d16564dff3b5bfa5688e906ae0b
parent 9fba7c5cf577f6b2e7537b894ce90ce81e352d77

Allow native rule analysis implementations to see Starlark-defined builtins

This implements the behavior of exports.bzl's `exported_to_java` dictionary: Any entry added to that dict becomes visible to all native rule implementations. This can be used to offload constants and helper logic into @_builtins, without necessarily first migrating everything that depends on it into @_builtins -- i.e. this lets us create a native-@_builtins sandwich.

A follow-up CL will make it easier to call Starlark-defined helper functions from native rules. Currently the caller would have to set up their own StarlarkThread and BazelStarlarkContext.

In principle, this feature of builtins injection should work for native aspects as well, but I haven't verified whether this CL makes it possible.

Note that there is no conceptual cyclic dependency between native logic and @_builtins. Native code can (in the future) expose internal-only symbols to @_builtins, and @_builtins can export helpers back to native code, but the former happens at rule class provider construction time, and the latter requires a RuleContext (or Skyframe environment). For instance, you can define "MyNativeProvider" in native code and instantiate it in a @_builtins .bzl, even at the top-level. But in order for the provider's constructor to access my_exported_builtins_defined_symbol, you'd have to pass in a RuleContext, which is only available during the analysis phase.

Implementation notes:

- CachingAnalysisEnvironment stores a StarlarkBuiltinsValue upon construction. The caller of the constructor is responsible for requesting this value from Skyframe and handling (or in the case of tests, ignoring) the possibility of a missing Skyframe dep, though the dep should not be missing since builtins were needed for the loading phase to succeed.

- CachingAnalysisEnvironment's access to the StarlarkSemantics now indirects through the builtins value, so the total number of Skyframe edges per configured target is not increased.

- TestRuleClassProvider#addMinimalRules is updated with definitions needed to run the analysis phase. Also created a separate list in TestConstants having just the default flags needed for this rule class provider. The notion behind addMinimalRules is that there should be some minimal set of core rules that are required by the package loading and analysis machinery, without necessarily bringing in the native rules we eventually want to migrate to Starlark.

Performance note: In theory, this CL can cause some configured targets to have an additional skyframe edge. This only occurs in cases where the configured target did not already request the StarlarkSemantics. All Starlark-defined rule types request the StarlarkSemantics, as do at least several Cc, Java, and Python rules (e.g. indirectly via helpers on RuleContext). So any increase should be pretty limited in scope.

Work toward #11437.

PiperOrigin-RevId: 348091304