Cygwin is the first platform to select `useGccNG`, and it is the natural
one: its libc is partly C++, so building `newlib-cygwin` needs C++ headers
before any libc exists. The monolithic compiler handles that with a
Cygwin-specific `langCC = stdenv.targetPlatform.isCygwin`; the split set
has a stage that provides them, `libstdcxx-no-libc`, which the preceding
commits add and wire in.
Derived from the platform rather than set on the example spec, so it holds
for any Cygwin triple, alongside the `useLLVM` rule it sits under. The
comment saying no platform selects it is retired here, since that is what
this changes.
This changes what `pkgsCross.x86_64-cygwin` builds with for everyone, not
only for callers passing the flag. Verified by building
`gccNGPackages.{libgcc,libstdcxx,libstdcxx-no-libc}` and `stdenv.cc` with
no `useGccNG` in the invocation; the derivations come out identical to
those built with the flag passed explicitly.
Assisted-by: Claude Code (Claude Opus 5)
`examples.nix` had settings that only repeated what the `config` already
implied. They read as if the platform were special, when it ought to be
the default. Now the default logic in `default.nix` ought to handle the
setting in question in a rule-based way so it is.
Change:
- `useLLVM` now covers
- UEFI
- MSVC CRT and C++ ABI
- Windows on AArch64 as well as FreeBSD and OpenBSD
- `libc` gains a UEFI case
hat retires seven `useLLVM` settings, eighteen `libc = "newlib"`, one
`libc = "bionic"`, and the `libc`/`linker` pair on the UEFI examples.
The remaining `libc`s in examples now means"this differs from what the
triple implies", which is true of the seven left: `newlib-nano`, the
mingw `msvcrt`/`ucrt` pairs those entries exist to distinguish, and
`mmix`, whose OS is `mmixware` rather than `none` so the bare-metal
default does not reach it. That one gains a comment.
No functional change. Elaborating all 87 platforms in
`lib.systems.examples` before and after gives byte-identical `config`,
`system`, `useLLVM`, `useGccNG`, `libc`, `linker` and
`rust.rustcTarget`. `mmix` surfaced that way, having regressed to
`native/impure`.
Assisted-by: Claude Code (Claude Opus 5)
This is guaranteed to be safe. The tree can be a simple string if the
fileset is the same as the root, but the `or` takes care of that. In the
`or` case, the tree is guaranteed to fail the isAttrs check, and so even
though the index is invalid, it won't matter.
Nothing could select the split GCC package set, so none of the fixes
below this commit were reachable from a normal build.
Add `useGccNG` alongside the existing `useLLVM`/`useZig`/`useArocc`
choices, and honour it where a compiler is picked: the cross stdenv takes
`gccNGPackages.gcc`, and `stdenvNoLibs`/`stdenvNoLibc` map to
`gccNoLibgcc` and `gccWithLibgcc`. That last pair is the point of the
split. Both currently fall back to `gccCrossLibcStdenv`, because the
monolithic compiler cannot distinguish them; `lib/systems/default.nix`
says as much next to `linker`, noting that we would like to choose the C
compiler and runtime library orthogonally but "due to the monolithic GCC
build we cannot actually make those choices independently". This is what
lifts that, the way the LLVM set already splits `clangNoCompilerRt` from
`clangNoLibc`.
`gccNGPackages` tracks `default-gcc-version` rather than naming a
release, so the split set and the monolithic `gcc` stay on the same one.
`useGccNG` defaults to `false` and no platform derives it, so no existing
build changes. Setting it on a platform spec is enough to exercise the
whole stack:
nix-build . -A stdenv.cc --arg crossSystem \
'{ config = "aarch64-unknown-linux-musl"; useGccNG = true; }'
The intent is to switch obscure low-tier platforms over to it soon --
NetBSD first -- so `ng` gets dogfooded somewhere the blast radius is
small. Those switches come separately.
Assisted-by: Claude Code (Claude Opus 5)
The stringLength check is equivalent at this point, but having to
actualy create the thunk for calling stringLength is likely slower than
just letting Nix handle the equality check.
The source filter runs on every path underneath the base directory, but
only on the few paths above it.
Reorder the prefix checks so the dominant below-the-base case does a
single substring + comparison instead of two, with an explicit branch
for the path being the base itself (which the previous first check also covered).
_normaliseTreeFilter strictly walks the entire file set tree on every
toSource call. File entries (null or a file type string) are already
normalised, so dispatch on the subtree inside the mapAttrs closure
instead of making a recursive call that immediately returns its
argument. This also avoids allocating an unused `path + "/${name}"`
argument thunk for every file.
This function runs once per directory node per union during lazy tree evaluation.
This makes it one of the hottest paths in lib.fileset for large trees.
It was measuared at ~9% of _total evaluation_ time in a very large monorepo.
This change is a 2-in-1:
- Return singleton lists directly to avoid rebuilding subtrees
- Use foldl instead of findFirstIndex
This is a hot path so the indexing arithmetic adds up.
Wasi P2 is different enough to Wasi P1 to warrant being treated entirely
separately, rather than as two minor variants of the same thing. P3 will
likewise want to be a different target.
I've left aliases in place; maybe eventually, those can be deprecated
and removed. I've tested this, but it's possible there might be breakage
somewhere (e.g., the canonical doubles for P1 have changed, though I
can't imagine why anyone would rely on that).
Fixes https://github.com/NixOS/nixpkgs/issues/435954
`attrListWith` re-emits every flag as an `lib.mkOrder` definition, so `argv` and
`flags` share one ordering space. Unadorned flags arrived at
`lib.modules.defaultOrderPriority`, the same priority as unadorned `argv`, and
only landed after `argv` because the declaring module's `config` happened to be
collected last.
Give flags that carry no ordering property of their own a priority of 1250,
between `lib.modules.defaultOrderPriority` and `lib.mkAfter`. Plain flags now
provably follow plain `argv`, `lib.mkAfter` on `argv` still places trailing
positional arguments after the flags, and an explicit `lib.mkOrder` on a flag is
honoured verbatim, which is what interleaving a sub-command among flags needs.
Also render path flag values through `pathOrStr`. `lib.cli.toCommandLine`
formats values with `lib.generators.mkValueStringDefault`, which has no case for
paths and aborts; coercing first yields the store path, matching `argv`.
Assisted-by: Claude:claude-opus-5
Add `process.flags` for declarative command-line flag generation
using `lib.cli.toCommandLine`, with per-flag ordering via valueMeta.
Add `process.flagFormat` to control flag rendering.
`process` gained `reloadCommand` and `reloadSignal`, and every service now
carries an assertion guarding their combination, so the expected values in
`test.nix` no longer matched.
Compare only `process.argv` and only the assertions that are violated, so the
test keeps expressing what it is about rather than restating every option.
Assisted-by: Claude:claude-opus-5
