subdirectories are affected by load statements flipping gazelle into legacy mode

[jmhodges]

So, if you have a load statement with the old go_proto_library statement like

  load("@io_bazel_rules_go//proto:go_proto_library.bzl", "go_proto_library")

in a parent BUILD.bazel file, the BUILD.bazel's in subdirectories will not have their proto targets updated even if that subdirectory has no old go_proto_library loads in it. This seems to be a automatic-legacy-mode thing triggering too much.

This also happens even if go_proto_library is not used in the parent BUILD.

I hit this when I left the load statement, unused but present, behind in the parent BUILD that I was moving the proto library out of (and trying to move it to a subdirectory as its own package).

[jayconrod]

Sorry, I meant to respond to this earlier.

This is mostly working as intended. If the proto mode isn't explicitly set, Gazelle attempts to infer it from a build file in the directory. The inferred proto mode is "inherited" by subdirectories. This is under the theory that if are using the legacy proto rules in one directory, you probably don't want to accidentally start using the new proto rules in a subdirectory.

The logic here ended up being more complicated and opaque than I like. However, I think migrating to new proto rules is probably too big a change to be automatic, and I didn't want to break people using the legacy proto rules by requiring a new option. At some point, we'll remove the legacy rules, and Gazelle won't generate filegroup rules for them anymore.

One thing that does not seem to be working is that if you explicitly set proto mode to default, it looks like it may drop down to legacy mode in a subdirectory. I should fix this so the inference does not override user intent.