Expand description
A resolution read as the types a settings struct holds.
The merge already validates every value against the type its setting declares, so most of this cannot fail. Three things keep it from being a formality, and they are the reason the errors here carry provenance rather than panicking:
- A post-merge hook writes with
Resolved::coerced, which is deliberately unchecked: the hook is where a CLI puts the rules only it knows, and making it validate would make it a second merge. A hook that writes-1to auintis a bug in the CLI, and the error has to say which setting and which hook —mise’s post-merge coercions touch a dozen settings. - A type only the tool understands (
any, a union) is not coerced by the merge at all, by declaration. The field that holds it is still concrete. - The field type narrows further than the declared one:
uintis ani64in the merge and au64in the struct, andintis ani64that a field may hold as something smaller.
Every failure is collected rather than returned at the first one. A user fixing a config file wants the whole list — the fleet’s hand-written folds return the first problem, so a file with three bad values takes three runs to fix.
Structs§
- Fold
- Reading a whole settings struct out of one resolution.
- Read
Error - Why a setting could not be read as the type its field holds.
- Read
Errors - Every setting that could not be read, in the order the registry declares them.
Enums§
- Read
Error Kind - The two ways reading a setting fails.