Now type checks the resulting function values and allows mkMerge and co.
Also indicates that the type check is done in the function body
Co-Authored-By: Robert Hensing <robert@roberthensing.nl>
Looks like these got left behind in the
kernelArch -> linuxArch migration.
Fixes:
* pkgsCross.powernv.linuxHeaders
* pkgsCross.riscv64.linuxHeaders
* pkgsCross.riscv32.linuxHeaders
and dependees
Immensely helpful when you want to see the changes a function makes to
its value as it passes through.
Example:
```
$ nix-instantiate --strict --eval -E '(with import ./lib; traceFnSeqN 2 "id" (x: x) { a.b.c = 3; })'
trace: {
fn = "id";
from = {
a = {
b = {…};
};
};
to = {
a = {
b = {…};
};
};
}
{ a = { b = { c = 3; }; }; }
```
This reverts commit 4ff1ab5a56.
We need this to type options like:
services.xserver.windowManager.xmonad.extraPackages that specify functions that
take an attribute set containing packages / plugins and return a list containing
a selection of the values in this set.
The reason we need a dedicated type for this is to have the correct merge
behaviour. Without the functionTo type merging multiple function option
definitions results in an evaluation error. The functionTo type merges
definitions by returning a new function that applies the functions of all the
definitions to the given input and merges the result.
(cherry picked from commit 7ed41ff5e7e633dd64866398ee497ac02736a3a5)
The `platform` field is pointless nesting: it's just stuff that happens
to be defined together, and that should be an implementation detail.
This instead makes `linux-kernel` and `gcc` top level fields in platform
configs. They join `rustc` there [all are optional], which was put there
and not in `platform` in anticipation of a change like this.
`linux-kernel.arch` in particular also becomes `linuxArch`, to match the
other `*Arch`es.
The next step after is this to combine the *specific* machines from
`lib.systems.platforms` with `lib.systems.examples`, keeping just the
"multiplatform" ones for defaulting.
For renames like
mkAliasOptionModule [ "services" "compton" ] [ "services" "picom" ]
where the target is an option set (like services.picom) instead of a single
option (like services.picom.enable), previously the renamed option type
was unset, leading to it being `types.unspecified`.
This changes it to be `types.submodule {}` instead, which makes more
sense.
Since 40e7be1 all ARM platforms that didn't have a parsed cpu version
(e.g. arm-none-eabi) would be handled as armv7l-hf-multiplatform which
did break building arm-trusted-platform packages for some targets (e.g.
rk3399).
Using pcBase as fallback, instead of armv7l-hf-multiplatform,
corresponds with the behaviour we had before 40e7be1.
We recently switched to more explicit GPL license names in line
with the SPDX change and GNU Foundation recommendations:
https://www.gnu.org/licenses/identify-licenses-clearly.html
This followed up older change to use the recommended SPDX ID
18a5e8c36b
but using the `-only` variant for these deprecated licenses too
makes it harder to check for them automatically.
Let’s switch to the appropriate SPDX ID again.
Previously the .enable option was used to encode the condition as well,
which lead to some oddness:
- In order to encode an assertion, one had to invert it
- To disable a check, one had to mkForce it
By introducing a separate .check option this is solved because:
- It can be used to encode assertions
- Disabling is done separately with .enable option, whose default can be
overridden without a mkForce
Previously this option was thought to be necessary to avoid infinite
recursion, but it actually isn't, since the check evaluation isn't fed
back into the module fixed-point.
