Description of the feature request:

Add a way for cc_toolchain configurations to declare cc_artifact_name_pattern entries with extensions that are not in ArtifactCategory.allowedExtensions, without requiring an upstream patch to ArtifactCategory.java for each new extension.

Proposed approach: an opt-in experimental flag (--experimental_cc_permissive_artifact_extensions) that, when enabled, skips the validation in CcToolchainFeaturesLib.java and uses the toolchain's declared extension as-is. Default off — existing toolchains see no behaviour change.

I have submitted a PR implementing my suggestion, but happy to discuss alternative shapes.

Which category does this issue belong to?

C++ Rules

What underlying problem are you trying to solve with this feature?

I work on a Bazel toolchain for a platform whose file extensions are private implementation details under NDA and cannot be disclosed upstream. Declaring those extensions via cc_artifact_name_pattern is rejected by the validation against the hardcoded ArtifactCategory.allowedExtensions. Adding them to ArtifactCategory.java — the usual workaround — is closed to me by the same NDA.

The same gap affects users on public platforms. The allow-list has grown one entry at a time (.exe, then .wasm), and requests for additional extensions like .axf (#5920) have remained open for years.

In my opinion, Bazel shouldn't try to enumerate every possible extension upstream — that's an open-ended task, especially if considering supporting proprietary or domain-specific platforms — and toolchain authors should be trusted to declare what's valid for their own toolchain

Which operating system are you running Bazel on?

Windows

What is the output of bazel info release?

release 9.1.0

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 ?

https://github.com/bazelbuild/bazel.git
78f6b47fdcb08909fa35d68e5eabe5ecebe72b97

Have you found anything relevant by searching the web?

• Not possible to use .axf as executable extension #5920 — request to add .axf for ARM cross-compilation; open since 2018, maintainer offered to accept a patch but the contribution never landed.
• List of allowed shared library file types should come from toolchain #17117 — umbrella: file types should come from the toolchain rather than being hardcoded. Referenced from the Bazel team's own TODO at CppFileTypes.java:241.
• Past addition of .wasm to the same enum: same pattern as Not possible to use .axf as executable extension #5920, addressed as a one-off.

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

No response