Flags out of scope for the command are ignored via --config

[justinhorvitz]

Description of the bug:

$ bazel build --verbose_test_summary
ERROR: --verbose_test_summary :: Unrecognized option: --verbose_test_summary

This is expected because --verbose_test_summary is only for the test command and not build. However, the following succeeds:

$ echo "build:abc --verbose_test_summary" >> .bazelrc
$ bazel build --config=abc

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.

No response

Which operating system are you running Bazel on?

No response

What is the output of bazel info release?

No response

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.

No response

Have you found anything relevant by searching the web?

No response

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

No response

[justinhorvitz]

@fmeum might this be related to your work on common (#18130)?

[fmeum]

That seems likely indeed. I'm OOO at the moment, but could look into it in ~2 weeks.

[fmeum]

I looked into this and confirm that my change causes this: In order to support ignoring common arguments in flag expansions, fallbackData is passed into the expansion function regardless of which commands the expanded arguments were specified on. As a result, all commands in config expansions behave like common.

The most straightforward fix I can think of is to annotate each individual arg with the fallbackData that applies to it in arguments to the parse functions in OptionsParser. I initially tried to make very changes and just run the parse function for each common or non-common run of args, but that resulted in issues with option priorities that I ultimately couldn't resolve since OptionsParserImplResults can't easily be merged.

I now think that the main parse function has to be modified to accept something like List<Pair<OptionsData, List<String>> as args. @justinhorvitz What do you think about that?

[justinhorvitz]

I looked into this too and see the complications. By "main parse function" do you mean this?

I think what you said about List<Pair<OptionsData, List<String>> is on the right track, but maybe it should be List<Pair<String, OptionsData>> since common and non-common args can be intermingled due to recursive config expansion. And we can make the type easier to understand by using a record ArgAndFallbackData(String arg, OptionsData fallbackData).

In the non-config case where all args get the same fallback data, we can use a lazy Lists.transform(args, arg -> new ArgAndFallbackData(arg, fallbackData)).

There are some potential complications with that argsPreProcessor that I didn't think through.

[fmeum]

I started out with List<Pair<String, OptionsData>> outside the function you linked and ran into issues when parsing a --copt -DFOO arg-by-arg, which doesn't work. I agree that with the logic moved into parse, that representation is better.

[iancha1992]

A fix for this issue has been included in Bazel 7.4.0 RC1. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.4.0rc1. Thanks!