compiler_param_file does not use custom flag prefix from "flag_groups"

[Warchant]

Description of the bug:

On Windows there is a need to enable "compiler_param_file" feature to solve 32k chars CreateProcessW limit.

If compiler does not support @ synax (g++ @file.txt) but requires custom flag, default feature implementation should be changed.

My version:

compiler_param_file_feature = feature(
        name = "compiler_param_file",
        enabled = True,
        flag_sets = [
            flag_set(
                actions = [
                    ACTION_NAMES.c_compile,
                    ACTION_NAMES.cpp_compile,
                ],
                flag_groups = [
                    flag_group(
                        flags = ["--cmd_file", "%{compiler_param_file}"],
                        expand_if_available = "compiler_param_file",
                    ),
                ],
            ),
        ],
    )

Feature is enabled, but I still see @ prefix instead of --cmd_file:

  external\ti\bin\cl6x.exe @bazel-out/wintic6000-fastbuild/bin/cpp/src/_objs/mycpplib_c/mycpplib.o.params

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?

Windows

What is the output of bazel info release?

5.1.1

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 master; git rev-parse HEAD ?

No response

Have you found anything relevant by searching the web?

No

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

No response

[sgowroji]

Hello @Warchant, Could you please provide complete steps to reproduce the above request. Thanks!

[fmeum]

@sgowroji Looks like the use of @ rather than the feature expansion is hard-coded here: https://cs.opensource.google/bazel/bazel/+/b671079e6cc3864cdbf6018474c9e417bc062453:src/main/java/com/google/devtools/build/lib/rules/cpp/CompileCommandLine.java;l=96.
A reproducer would still be a useful base for an integration test added after this has been fixed.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[Warchant]

not stale

Issue still exists

[fmeum]

@bazelbuild/triage

[hauserx]

Similar issue was solved for linker_param_file in #18074 (see b5cfea5)

Maybe it could be solved by similar logic here as well? (cc @comius)

New linker_param_file logic:

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/LinkCommandLine.java

Line 154 in 2544063

if (paramFile != null) {

Current compiler_param_file logic:

bazel/src/main/java/com/google/devtools/build/lib/rules/cpp/CompileCommandLine.java

Line 95 in 2544063

if (parameterFilePath != null) {