Fabian Meumertzheim

The current state is that this can be enabled with `--experimental_async_execution`, but it comes with a performance penalty.

@pauldraper This is an older commit, the flag has been reimplemented since.

I think that this is expected, both `package` and `repo` are equivalent to setting the corresponding attribute on the rules, but that by itself doesn't result in the providers being...

Gazelle refers to `rules_go` as `io_bazel_rules_go` in the load statement that fails for you: https://github.com/bazelbuild/bazel-gazelle/blob/852fdcfe7d6cdfcc72b1275a2200a1e131bf0203/cmd/gazelle/BUILD.bazel#L1 Are you sure that you are using upstream Gazelle and don't have any patches or...

> The error message also refers to cannot find rules_go not io_bazel_rules_go, which looks weird. Yeah, that's also what confuses me. Could you try looking at the contents of the...

Super weird, that file doesn't even contain the failing reference to `@rules_go`. I have no idea what's here, I fear the only path forward is for you to cut down...

It's still weird since build files aren't cached in that kind of cache. But I don't think it's worth investigating further unless it shows up again.

It's going to be hard to debug this without a reproducing sample. The interaction between WORKSPACE and MODULE.bazel is subtle enough that I won't rule this out, but if nothing...

There's also https://github.com/bazelbuild/bazel-gazelle/pull/1888, so @TvdW and you might want to align.

Patches are applied after Gazelle is run, so this is expected. We could have "after Gazelle patches", but I'm not sure whether that's worth the complexity. How much larger is...