Poor diagnostics for set -> string type coercion errors. #561
Comments
|
These can get very ugly. Right now the evaluator with and no trace at all. It took me hours before I found where the problem was, among the thousands of (texlive) packages. |
The package "version" clashed with bin.version and it took ages to debug NixOS/nix#561 (comment)
|
Using my latest noisy-nix commits (#612) the errors show as follows: Maybe someone will want to review them... |
|
@Mathnerd314: That looks quite a bit better. |
|
Similar: #963 |
domenkozar
added
improvement
UX
|
I get this error, for my It's obviously time to tidy up, but until then: Are there any debugging tactics to track the problematic value down? 🙏 |
|
I have use binary search. Comment out half of the file, test, repeat. |
|
Reminds me of:
😉 |
domenkozar
added
error-messages
|
I marked this as stale due to inactivity. → More info |
|
bump to unstalify |
do a manual stack trace, by inserting dozens of {
# TRACE
#someAttr = "some value";
someAttr =
lib.traceSeqN 2 { loc = "line 1234"; someAttr = "some value"; }
"some value"
;
}... to get a feel for the program flow make
|
Previously, type or coercion errors for string interpolation, path
interpolation, and plus expressions were always reported at the
beginning of the outer expression. This leads to confusing evaluation
error messages making it hard to accurately diagnose and then fix the
error.
For example, errors were reported as follows.
```
cannot coerce an integer to a string
1| let foo = 7; in "bar" + foo
| ^
cannot add a string to an integer
1| let foo = "bar"; in 4 + foo
| ^
cannot coerce an integer to a string
1| let foo = 7; in "x${foo}"
| ^
```
This commit changes the ExprConcatStrings expression vector to store a
sequence of expressions *and* their expansion locations so that error
locations can be reported accurately. For interpolation, the error is
reported at the beginning of the entire `${foo}`, not at the beginning
of `foo` because I thought this was slightly clearer. The previous
errors are now reported as:
```
cannot coerce an integer to a string
1| let foo = 7; in "bar" + foo
| ^
cannot add a string to an integer
1| let foo = "bar"; in 4 + foo
| ^
cannot coerce an integer to a string
1| let foo = 7; in "x${foo}"
| ^
```
The error is reported at this kind of precise location even for
multi-line indented strings.
This probably helps with at least some of the cases mentioned in NixOS#561
|
I marked this as stale due to inactivity. → More info |
|
The trace is even worse if you accidentally attempt to access an attset with attrset as a key (e.g., let
attr = { foo = "bar"; };
key = {};
in attr.${key}$ nix-instantiate --version
nix-instantiate (Nix) 2.13.3
$ nix-instantiate --eval bad-trace.nix --show-trace
error: value is a set while a string was expected
at «none»:0: (source not available)Same with 2.3: $ nix-instantiate --version
nix-instantiate (Nix) 2.3.16
$ nix-instantiate --eval bad-trace.nix --show-trace
error: value is a set while a string was expected |
* update documentation project outline, add details as discussed with the documentation team, in order to brief project participants.
I found this error quite unhelpful:
The position given for the error is within the NixOS source, so I figured I'd run it again with
--show-trace.Eventually I traced the error to my use of
ghc(a set) rather thanghc.ghc784(a package) inenvironment.systemPackages. The trace fails to mentionghc, its contents or its location in the configuration file (/etc/nixos/configuration:64). Ideally, I would have liked an error like this:The text was updated successfully, but these errors were encountered: