Starlark build setting invoking go_context throws an exception

[fmeum]

Description of the problem:

Bazel fails with java.lang.IllegalStateException: method invocation returned null: toolchains() when invoking rules_go's go_context from a Starlark build setting rule.

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

I have created a minimal example as this gist. If the line go_context(ctx) is replaced with pass, the build succeeds without an exception. I suspect that rules_go is not really needed to trigger the exception here, but don't know enough about toolchains to minimize this example further.

I found this example while trying to create a config setting that would automatically generate code based on its current value.

What operating system are you running Bazel on?

Linux

What's the output of bazel info release?

release 3.7.1

Have you found anything relevant by searching the web?

Unfortunately not.

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

See https://gist.github.com/fmeum/86bd43948210ba2fc9fb64f6a3a3f6af#file-trace for the trace.

[fmeum]

I can confirm that this is still reproducible with 4.0.0. rc2.

[brandjon]

@comius Is rules_go in any way using native rules or is this definitely a starlark issue?

[brandjon]

Looking more closely, the error occurs in StarlarkRuleContext#toolchains, and indicates that either the RuleContext has no toolchainContexts collection or no default toolchain context. Forwarding to configurability team.

[brandjon]

@katre fyi

[katre]

You cannot use toolchains (or anything that uses toolchains) from a build setting (see RuleClass.Builder.buil, where this is enforced).

However, it should be a clear error and not crash the build.

What were you actually trying to do by invoking a Go build actions in a build setting?

[fmeum]

What were you actually trying to do by invoking a Go build actions in a build setting?

My plan was to add providers to the build setting returning generated code that exposes the value of the build setting, e.g. as a Go constant.

[katre]

Build settings shouldn't ever generate actions. We aren't currently enforcing this but might in the future. If you want this I'd suggest a bit of indirection: one rule to create the build setting, and then another rule that checks the setting and generates the constants, which other targets can depend on.

[katre]

To expand on my previous comment: build settings are inherently part of the configuration, and so are loaded frequently and eagerly. If they did register actions, we'd see a large number of actions created (in essentially every configuration) but not being used, leading to memory bloat and slowing down analysis of every target.