warnIf sends our warning message through a function call, even if the
warning condition doesn't trigger. This requires a lot of thunk
allocation that can be easily avoided.
- When `evalModules` is called without deprecated `args`/`check` parameters (the common case), avoid `modules ++ []` which copies the entire module list for no reason.
- `collectModules` was calling `collectStructuredModules` twice with identical arguments — once for `filterModules` and once for `toGraph`. Share the result via a `let` binding.
- Replace `zipAttrsWith (n: v: v)` with `zipAttrs`
- Replace `concatMap` with `filter`+`map` in `filterOverrides'`
NixOS minimal eval improvement: -5.0% list_concats, -1.2%
nrFunctionCalls, -0.7% nrThunks, -1.0% envs, -1.5% list_bytes.
Replace `(optional (opt ? default) { ... }) ++ defs` with a direct
if/then/else. When the option has no default, this skips both the
list allocation and the ++ concat entirely. Most options do have
defaults, but even then we avoid the `optional` function call overhead
(closure + env allocation).
On NixOS minimal eval: -45K function calls (-0.93%), -3.7K list
concats (-1.93%).
The vast majority of option definitions reaching mergeDefinitions are
singletons whose value carries no _type wrapper (mkIf/mkMerge/
mkOverride/mkOrder). For those, the dischargeProperties ->
filterOverrides' -> sortProperties pipeline is a no-op yet still costs
~125k function calls and ~70k thunks on a minimal NixOS system eval.
Detect this case up front and reuse the input list as
defsFinal'.values, keeping the addErrorContext around the value probe
so error traces still point at the defining file. highestPrio is
defaultOverridePriority by construction.
A single-fold filterOverrides' was prototyped but allocates an attrset
per definition and regressed gc.totalBytes; with the fast path in
place that function is no longer hot enough to matter.
NIX_SHOW_STATS, minimal `nix-instantiate ./nixos -A system`:
nrFunctionCalls 5490285 -> 5365172 (-125113)
nrThunks 8182569 -> 8112150 (-70419)
gc.totalBytes 640.0M -> 635.2M (-4.8M)
If an attrset option was given a definition like:
{ system = lib.mkIf true false; }
Before this change, we get the non-explanatory error message:
error: expected a set but found a Boolean: true
With the stack trace having nothing to do with the module involved.
After this change, we get the better:
error: In module `[...]', you're trying to define a value of type `bool' [...]
Which names the actual module involved.
- concrete types start with uppercase: Int, String, Bool, Derivation,
etc.
- type variables start with lowercase: a, b, etc.
- list:
- use `[x]` for homogeneous lists instead of `List x` or `[ x ]`
- use `List` for heterogeneous lists (not that common in `lib`)
- attr:
- use `AttrSet` for a generic attribute set type
- use `{ key1 :: Type1; key2 :: Type2; ... }` for adding signatures
for known attribute names and types
- use `{ key1 = value1; key2 = value2; ... }` for adding attributes
with known literals
- end with an ellipsis (`...`) if the set can contain unknown
attributes
- use `{ [String] :: x }` if all the attributes has the same type `x`
- prefer `Any` over `a` if the latter is not reused
Unfortunately, we don't have a good enough way to discern this
possibility. Technically we could add yet another attribute, but
that does not seem to be worth the cost at this point, in terms
of complexity and possibly even performance.
I take the blame for this one. I identified the need for the second
merge commit in review but didn't require it in the first merge.
These changes really should have been done in a single merge.
That would have prevented this situation.
This change introduces the suggesting of possible valid option names for
a given invalid option, based on the keys of said invalid option's
parent attrset. That is, `foo.bar.baz` will only be suggested keys from
`foo.bar`, while `(config).baz` will only be suggested keys from the
toplevel.
This allows individual types to add attributes that would be discarded during normal evaluation.
Some examples:
types.submodule performs a submodule evluation which yields an 'evalModules' result.
It returns '.config' but makes the original result accessible via 'valueMeta' allowing introspection of '.options' and all other kinds of module evaluation results
types.attrsOf returns an attribute set of the nestedType.
It makes each valueMeta available under the corresponding attribute name.
hsjobeki: Using config in imports is possible in general. But its not possible to do conditional imports where the condition depends on config. Thats two different statements.
Co-authored-by: Johannes Kirschbauer <hsjobeki+github@gmail.com>
The `importApply` docs reference using the `_key` attr along with
`importApply` or `_file`, however the actual attr name used by the
module system is `key`.
