<title>fix(nix/yants): make (typedef …).checkType return a result set</title>
<updated>2021-02-19T16:14:55+00:00</updated>
<author>
<name>sterni</name>
<email>sternenseemann@systemli.org</email>
...</author>
<published>2021-02-18T00:33:27+00:00</published>
<link rel="alternate" type="text/html" href="http://code.tvl.fyi/commit/?id=690994a28cc3045c14268996144e9302fa43bf68"/>
<id>urn:sha1:690994a28cc3045c14268996144e9302fa43bf68</id>
<content type="text">
Previously, for types defined using typedef (like all primitive types)
type.checkType would return a boolean. This is largely fine since in
most places `type.checkToBool (type.checkType x)` or similar is used.
However, some functions actually take type.checkType up on the promise
that it returns a set of the form:
{
ok = <bool>;
err = <option string>;
}
This is the case for restrict which has checkToBool = v: v.ok; and will
generate a proper set except if `t.checkToBool (t.checkType v) == false`
in which case it will return t.checkType v. If t was a primitive type or
defined using typedef, previously `t.checkType v` would be a boolean
which meant as soon as (restrict …).checkToBool was called on a restrict
checkType result in cases where the wrapped type didn't match, an
unrelated error would be thrown:
nix-repl> with nix.yants; restrict "foo" (_: true) int "lol"
error: value is a boolean while a set was expected, at /home/lukas/src/depot/nix/yants/default.nix:38:39
This is fixed by making typedef return a proper set from checkType and
adjusting its checkToBool accordingly.
Unfortunately I don't think we can easily add test cases for this except
by using recursive nix or VM tests as there is no way to introspect
error messages.
Change-Id: I96a7be065630f04ca33358f21809284911ec14fe
Reviewed-on: https://cl.tvl.fyi/c/depot/+/2536
Tested-by: BuildkiteCI
Reviewed-by: tazjin <mail@tazj.in>
Reviewed-by: Profpatsch <mail@profpatsch.de>
</content>