Refactor features implementation

.github/workflows/autosd.yml

@@ -41,7 +41,7 @@ jobs:
           cache-save: ${{ github.event_name == 'push' }}
       - name: Bazel Build (basic)
         run: |
-          bazel build --lockfile_mode=error --config=x86_64-linux-autosd10 -- //:language_and_standards_tests //:feature_verification_tests
+          bazel build --lockfile_mode=error --config=x86_64-linux-autosd10 --features=-default_link_flags -- //:language_and_standards_tests //:feature_verification_tests
       - name: Guardrail (no legacy features)
         run: |
-          bazel test --lockfile_mode=error --config=x86_64-linux-autosd10 -- //:guardrail_tests
+          bazel test --lockfile_mode=error --config=x86_64-linux-autosd10 --features=-default_link_flags -- //:guardrail_tests

docs/features.md

@@ -1,9 +1,7 @@
 # Toolchain Features
 
-These are the `cc_toolchain` features defined by the toolchain configs in
-[`templates/linux/cc_toolchain_config.bzl.template`](../templates/linux/cc_toolchain_config.bzl.template)
-and
-[`templates/qnx/cc_toolchain_config.bzl.template`](../templates/qnx/cc_toolchain_config.bzl.template).
+These are the `cc_toolchain` features defined by the shared toolchain config in
+[`templates/cc_toolchain_config.bzl.template`](../templates/cc_toolchain_config.bzl.template).
 
 Both toolchains enable **`no_legacy_features`**, which turns off the features
 Bazel would otherwise add implicitly. As a result every flag the toolchain emits

docs/generation_flow.md

@@ -23,10 +23,15 @@ toolchain repository through these steps:
 1. `extensions/gcc.bzl` collects `gcc.toolchain` and `gcc.sdp` tags.
 2. Package metadata is resolved from `packages/version_matrix.bzl` or from an
    explicit `gcc.sdp` declaration.
-3. `rules/gcc.bzl` renders a BUILD file and configuration files into a new
-   repository.
-4. Platform-specific templates from `templates/linux/` or `templates/qnx/` are
-   populated with CPU, version, licensing, and flag information.
+3. `rules/gcc.bzl` renders the shared `templates/BUILD.template` and
+   `templates/cc_toolchain_config.bzl.template` into a new repository,
+   substituting CPU, version, licensing, and flag placeholders.
+4. The rendered `BUILD` file wires in the toolchain's feature set:
+   per-instance features created at generation time (extra compile/link
+   flags, sysroot link flags, compiler library search paths) plus the
+   ordered `known_features`/`enabled_features` lists from
+   `features/custom/linux/` or `features/custom/qnx/`, which reference the
+   reusable `cc_feature` targets under `features/native/`.
 5. The consuming workspace enables the generated toolchain with
    `--extra_toolchains` and compatible platform constraints.
 
@@ -44,27 +49,26 @@ representation needed by the templates and repository rules.
 
 `rules/gcc.bzl`
 
-Generates the toolchain repository. It decides whether Linux or QNX template
-content is required, performs placeholder substitution, and emits the final
-`BUILD`, `cc_toolchain_config.bzl`, `flags.bzl`, and Linux `gcov` wrapper
-files.
+Generates the toolchain repository. It performs placeholder substitution and
+emits the final `BUILD`, `cc_toolchain_config.bzl`, and `gcov` wrapper files,
+substituting OS-specific values (e.g. `compiler`, `abi_version`,
+`toolchain_identifier`) into the shared templates below.
 
-## Template Families
-
-Linux templates:
+`features/`
 
-- `templates/linux/cc_toolchain_config.bzl.template`
-- `templates/linux/cc_toolchain_flags.bzl.template`
-- `templates/linux/cc_gcov_wrapper.template`
+Defines the toolchain's `cc_feature` / `cc_args` targets with
+`@rules_cc//cc/toolchains`. `features/native/` holds one reusable target per
+toolchain feature; `features/custom/linux/` and `features/custom/qnx/` hold
+OS-specific features plus the ordered `known_features`/`enabled_features`
+lists that `templates/BUILD.template` passes to `cc_toolchain_config`.
 
-QNX templates:
-
-- `templates/qnx/cc_toolchain_config.bzl.template`
-- `templates/qnx/cc_toolchain_flags.bzl.template`
+## Template Families
 
-Shared template:
+Shared templates (used by both Linux and QNX):
 
+- `templates/cc_toolchain_config.bzl.template`
 - `templates/BUILD.template`
+- `templates/cc_gcov_wrapper.template`
 
 ## Important Implementation Details
 

docs/maintenance.md

@@ -73,6 +73,59 @@ means a broken build rather than a silent fallback.
 > libraries (e.g. AutoSD) cannot link fully static binaries, so that feature is
 > opt-in and its test is marked incompatible with such platforms.
 
+## Toolchain Feature Catalog (`features/`)
+
+`features/` is the live source of the toolchain's `cc_feature` / `cc_args`
+definitions, built with `@rules_cc//cc/toolchains`. It replaced the legacy
+`feature()` Starlark calls that used to live directly in the per-OS
+`cc_toolchain_config.bzl.template` files; `templates/cc_toolchain_config.bzl.template`
+now only implements the `cc_toolchain_config` rule and turns
+`known_features`/`enabled_features` labels into the toolchain's feature list —
+it defines no features of its own.
+
+- `features/native/`: one reusable `cc_feature`/`cc_args` target per toolchain
+  feature (`default_compile_flags`, `include_paths`, `pic`,
+  `sysroot_link_flags`, ...), including the capability markers (`dbg`, `opt`,
+  `supports_pic`, ...). These mirror the removed legacy Bazel C++ features
+  one-for-one.
+- `features/custom/linux/` and `features/custom/qnx/`: OS-specific features
+  not covered by the native set (QNX `sdp_env`, `gcc_version_flags`), plus
+  `make_cc_features.bzl`, which defines the ordered `_LINUX_FEATURES` /
+  `_QNX_FEATURES` lists of `(label, initially_enabled)` pairs. Order here
+  mirrors the previous templates' `features = [...]` order exactly, since
+  feature order determines command-line flag order. `get_feature_lists()`
+  returns `(known_features, enabled_features)`, and `templates/BUILD.template`
+  passes those straight into `cc_toolchain_config`'s `known_features` /
+  `enabled_features` attributes — this is what the generated toolchain
+  actually uses.
+- Per-instance features whose content is dynamic per toolchain instance —
+  `extra_compile_flags`, `extra_c_compile_flags`, `extra_cxx_compile_flags`,
+  `extra_link_flags`, `compiler_library_search_paths`, `sysroot_link_flags` —
+  are *not* static `features/native/*` targets. Instead
+  `templates/BUILD.template` creates them at generation time (via
+  `make_extra_compile_features()`, `make_extra_link_features()`,
+  `make_compiler_library_search_paths()`, and `make_sysroot_link_flags()`, all
+  defined under `features/native/<name>/features.bzl`) using fixed local
+  target names (`:extra_compile_flags`, etc.), and `_LINUX_FEATURES` /
+  `_QNX_FEATURES` reference those fixed names at the correct position in the
+  ordered list. This keeps both feature order (repo-controlled) and
+  per-instance dynamic content (caller-controlled via `gcc.toolchain(...)`
+  attributes).
+- `all_wall_warnings`, `minimal_warnings`, `strict_warnings`, and
+  `warnings_as_errors` are not defined anywhere in this repository — they were
+  removed and are superseded by `score_cpp_policies`, injected via
+  `extra_known_features` / `extra_enabled_features` (same mechanism as the
+  sanitizers).
+
+> **Known cleanup item:** `features/BUILD` also defines two `cc_feature_set`
+> targets (`linux` and `qnx`) that group the same features for
+> `requires_any_of`/`requires_all_of`-style constraints. Nothing in this
+> repository currently references them — `cc_toolchain_config`'s
+> `known_features`/`enabled_features` attributes require individual
+> `FeatureInfo`-providing labels, not a `cc_feature_set` grouping (see the
+> `compute_feature_lists()` docstring in `features/make_cc_features.bzl`).
+> These should either be wired to a consumer or removed.
+
 ## Common Gotchas
 
 - runtime-specific toolchains may need extra include and link flags that do not

docs/migration_guide.md

@@ -56,18 +56,15 @@ reproducible toolchain:
 
 ### The explicit (current) model
 
-Both toolchain configs set:
-
-```starlark
-no_legacy_features_feature = feature(name = "no_legacy_features", enabled = True)
-```
+Both toolchain configs always enable `no_legacy_features` — a `cc_feature`
+defined in `features/native/markers` and listed as initially-enabled in the
+ordered feature list built by `features/custom/linux/make_cc_features.bzl` /
+`features/custom/qnx/make_cc_features.bzl`.
 
 With this enabled, Bazel injects **nothing** implicitly. Every compile, link,
 and archive flag must come from a feature (or other toolchain wiring) declared
-explicitly in
-[`templates/linux/cc_toolchain_config.bzl.template`](../templates/linux/cc_toolchain_config.bzl.template)
-or
-[`templates/qnx/cc_toolchain_config.bzl.template`](../templates/qnx/cc_toolchain_config.bzl.template).
+explicitly under [`features/`](../features) and wired in by
+[`templates/cc_toolchain_config.bzl.template`](../templates/cc_toolchain_config.bzl.template).
 
 The practical consequence: the command line is now fully described by this
 repository's feature set. What you see documented in
@@ -95,8 +92,8 @@ toolchain, are summarized below.
 | `--sysroot` handling | **Supported, explicit (Linux)** | `sysroot_link_flags` at link; compile relies on `cxx_builtin_include_directories` |
 | Compiler / archiver / strip tool binding | **Supported, wiring** | `action_config` entries, not legacy `tool_paths` |
 | `gcov` | **Supported, wiring** | `tool_paths` (`gcov_wrapper`) |
-| Warnings (e.g. `-Wall`) added by default | **Linux: opt-in · QNX: on by default** | `minimal_warnings` (includes `-Wall`) is enabled by default on QNX but disabled on Linux. `strict_warnings` / `all_wall_warnings` are opt-in on both. |
-| `-Werror` | **Not implicit — opt-in** | `warnings_as_errors` (disabled by default) |
+| Warnings (e.g. `-Wall`) added by default | **Not part of this toolchain — injected** | `minimal_warnings` / `strict_warnings` / `all_wall_warnings` are defined by `score_cpp_policies`, not this toolchain, and only become available once brought in via `extra_known_features` / `extra_enabled_features`. |
+| `-Werror` | **Not part of this toolchain — injected** | `warnings_as_errors`, defined by `score_cpp_policies` and injected the same way as the other warning features. |
 | Sanitizers (asan/lsan/tsan/ubsan) | **Not part of this toolchain — injected (Linux)** | Defined by `score_cpp_policies` (`score_asan` / `score_lsan` / `score_tsan` / `score_ubsan`) and brought in via `extra_known_features` / `extra_enabled_features` |
 | Fully static link (`-static`) | **Not implicit — opt-in** | `fully_static_link` (disabled by default) |
 | `-pthread` | **Not implicit — opt-in (Linux)** | `use_pthread` (disabled by default) |
@@ -106,11 +103,11 @@ toolchain, are summarized below.
 Three categories deserve special attention because they are the most frequent
 migration surprises:
 
-1. **Warnings differ by platform.** On **Linux**, all warning features are
-   opt-in — if you expected `-Wall`-style warnings you must enable them. On
-   **QNX**, `minimal_warnings` (which includes `-Wall`) is enabled by default,
-   so those warnings do *not* disappear; `strict_warnings`,
-   `all_wall_warnings`, and `-Werror` remain opt-in on both platforms.
+1. **Warnings are not part of this toolchain on either platform.** All
+   warning-level features (`minimal_warnings`, `strict_warnings`,
+   `all_wall_warnings`, `warnings_as_errors`/`-Werror`) are defined by
+   `score_cpp_policies` and only become available once injected via
+   `extra_known_features` / `extra_enabled_features`.
 2. **`-pthread` and fully-static linking are opt-in.** These emit nothing until
    you enable the corresponding feature.
 3. **Sanitizers are not part of this toolchain.** They are defined by the
@@ -212,13 +209,21 @@ now?" case.
 
 **Symptom:** Code that used to warn (or fail on warnings) now builds clean.
 
-**Cause:** On **Linux**, all warning features are opt-in, so nothing is added by
-default under `no_legacy_features`. On **QNX**, `minimal_warnings` (`-Wall`) is
-enabled by default, but `strict_warnings`, `all_wall_warnings`, and `-Werror`
-are still opt-in — so stricter diagnostics can still appear to "disappear".
+**Cause:** Warning-level features are not defined by this toolchain at all —
+they are defined by `score_cpp_policies` and are only available once injected
+into the toolchain via `extra_known_features` / `extra_enabled_features` (see
+[Extension API](extension_api.md#feature-injection)).
 
-**Fix:** Enable the warning features you want. To restore a strict, fail-fast
-profile build-wide:
+**Fix:** Inject the desired warning feature(s) from `score_cpp_policies` on
+`gcc.toolchain(...)`, then enable them like any other feature:
+
+```starlark
+gcc.toolchain(
+    name = "score_gcc_toolchain",
+    ...
+    extra_known_features = ["@score_cpp_policies//features:strict_warnings", "@score_cpp_policies//features:warnings_as_errors"],
+)
+```
 
 ```bash
 # .bazelrc
@@ -236,6 +241,9 @@ cc_library(
 )
 ```
 
+> The exact `score_cpp_policies` feature labels above are illustrative — see
+> that module's documentation for the authoritative target names.
+
 ### Scenario B — "Undefined reference to pthread symbols"
 
 **Symptom:** Links fail with `pthread_*` undefined references.

docs/repository_layout.md

@@ -25,6 +25,7 @@ The repository is organized by subsystem rather than by platform product:
 |- tests/       Test workspace and validation suites
 |- extensions/  Bzlmod extension entry points
 |- packages/    Toolchain package descriptors and version matrix
+|- features/    Declarative cc_feature/cc_args toolchain-feature definitions
 |- rules/       Repository rules and shared helpers
 |- templates/   Generated file templates for toolchain repositories
 `- tools/       Standalone utility scripts
@@ -50,13 +51,24 @@ archives. The most important file is `packages/version_matrix.bzl`, which maps
 logical toolchain identifiers to URLs, checksums, build files, and any
 required extra flags.
 
+`features/`
+
+Holds declarative `cc_feature` / `cc_args` toolchain-feature definitions built
+with `@rules_cc//cc/toolchains`. `features/native/` has one reusable target
+per toolchain feature (mirroring the legacy Bazel C++ features); the
+OS-specific `features/custom/linux/` and `features/custom/qnx/` packages hold
+platform-only features (e.g. QNX `sdp_env`, `gcc_version_flags`) plus the
+ordered `known_features`/`enabled_features` lists that
+`templates/BUILD.template` passes to `cc_toolchain_config`.
+
 `templates/`
 
-Holds the template files used by repository rules. These templates are
-rendered into the generated toolchain repository and differ between Linux and
-QNX because the execution environment, sysroot layout, and licensing model are
-different.
-> NOTE: Future plan is to have a single template for toolchain configuration.
+Holds the shared template files rendered by repository rules into the
+generated toolchain repository: `BUILD.template`,
+`cc_toolchain_config.bzl.template`, and `cc_gcov_wrapper.template`. A single
+template pair now covers both Linux and QNX; OS-specific behavior comes from
+placeholder substitution in `rules/gcc.bzl` and from the OS-specific feature
+lists in `features/custom/`, not from separate template directories.
 
 `tests/`
 

extensions/gcc.bzl

@@ -209,8 +209,7 @@ def _get_toolchains(tags):
     toolchains = []
     for tag in tags:
         toolchain = {
-            "cc_toolchain_config": "@score_bazel_cpp_toolchains//templates/{}:cc_toolchain_config.bzl.template".format(tag.target_os),
-            "cc_toolchain_flags": "@score_bazel_cpp_toolchains//templates/{}:cc_toolchain_flags.bzl.template".format(tag.target_os),
+            "cc_toolchain_config": "@score_bazel_cpp_toolchains//templates:cc_toolchain_config.bzl.template",
             "gcc_version": tag.version,
             "name": tag.name,
             "use_base_constraints_only": tag.use_base_constraints_only,
@@ -424,7 +423,6 @@ def _impl(mctx):
             tc_runtime_ecosystem = toolchain_info["tc_runtime_ecosystem"],
             gcc_version = toolchain_info["gcc_version"],
             cc_toolchain_config = toolchain_info["cc_toolchain_config"],
-            cc_toolchain_flags = toolchain_info["cc_toolchain_flags"],
             use_base_constraints_only = toolchain_info["use_base_constraints_only"],
         )