Print the value in `value is X while a Y is expected` error by 9999years · Pull Request #9753 · NixOS/nix

9999years · 2024-01-12T18:04:46Z

Motivation

Adds the failing value to value is <TYPE> while a <TYPE> is expected error messages.

Context

Take two of #9554 now that #9606 is merged.
Partial fix for #561, in particular #561 (comment).

Priorities

Add 👍 to pull requests you find important.

doc/manual/rl-next/print-value-in-type-error.md

src/libexpr/print-options.hh

Ma27

This is a very nice change!

I played a bit around with this and it seems to be working fine. I even through this against some more complex evaluations involving flake-parts with custom modules and that seems to be producing helpful results.

From what I can tell, this looks OK code-wise from what I can tell - haven't been doing contributing much to the Nix codebase recently.

One issue I noticed however is that the opening bracket of a list/attr-set is magenta, the closing bracket isn't, i.e.

"[...] while a set  was expected: " ANSI_MAGENTA "[" ANSI_CYAN " 2 3 " ANSI_NORMAL "]"

E.g. reproducible with ./result/bin/nix-instantiate --eval -E '[ 1 2 ] // {}'.

Also, I'm wondering if it'd make sense to do a little bit of pretty-printing for lists and attr-sets, though that'd require changes on existing code, so that's a follow-up I guess.

Ma27 · 2024-01-20T15:01:07Z

src/libexpr/eval.cc

-#include <iostream>
 #include <fstream>
 #include <functional>
+#include <strstream>


Btw any particular reason for using strstream here? That is deprecated for quite a while and I just realized that it doesn't build with clang (used gcc last time).
Also, reversing this change seems fine as well.

Nope, fixed this to use iostream instead.

Needed to fix the build with clang. See also NixOS#9753 (comment)

Low-hanging fruit in the spirit of NixOS#9753 and NixOS#9754 (means 9999years did all the hard work already). This basically prints out what was attempted to be called as function, i.e. map (import <nixpkgs> {}) [ 1 2 3 ] now gives the following error message: error: … while calling the 'map' builtin at «string»:1:1: 1| map (import <nixpkgs> {}) [ 1 2 3 ] | ^ … while evaluating the first argument passed to builtins.map error: expected a function but found a set: { _type = "pkgs"; AAAAAASomeThingsFailToEvaluate = «thunk»; AMB-plugins = «thunk»; ArchiSteamFarm = «thunk»; BeatSaberModManager = «thunk»; CHOWTapeModel = «thunk»; ChowCentaur = «thunk»; ChowKick = «thunk»; ChowPhaser = «thunk»; CoinMP = «thunk»; «18783 attributes elided»}

Adds the failing value to `value is <TYPE> while a <TYPE> is expected` error messages.

roberth · 2024-01-22T18:57:52Z

One issue I noticed however is that the opening bracket of a list/attr-set is magenta, the closing bracket isn't, i.e.
"[...] while a set  was expected: " ANSI_MAGENTA "[" ANSI_CYAN " 2 3 " ANSI_NORMAL "]"
E.g. reproducible with ./result/bin/nix-instantiate --eval -E '[ 1 2 ] // {}'.

This is caused by the formatting logic behind hintformat - specifically how the default item type is printed via yellowtxt (bad name; was about warnings, and those are magenta now).
It tries to print the argument in magenta, but printValue does not know that it "should" reset to that color state. I'm not sure that it should. It might be nice to reset to bold, to distinguish it from the fixed parts of the error message, but that might be over-engineering it.

As for the magenta token, you could wrap all expressions in normaltxt, or perhaps by add some extra overload of hintformat::operator%. In the latter case, you might make the call sites a bit more concise.

9999years · 2024-01-22T19:44:00Z

That's a good idea. Can I leave it to a follow-up PR to keep this focused?

roberth · 2024-01-22T21:18:55Z

follow-up PR

👍

Low-hanging fruit in the spirit of NixOS#9753 and NixOS#9754 (means 9999years did all the hard work already). This basically prints out what was attempted to be called as function, i.e. map (import <nixpkgs> {}) [ 1 2 3 ] now gives the following error message: error: … while calling the 'map' builtin at «string»:1:1: 1| map (import <nixpkgs> {}) [ 1 2 3 ] | ^ … while evaluating the first argument passed to builtins.map error: expected a function but found a set: { _type = "pkgs"; AAAAAASomeThingsFailToEvaluate = «thunk»; AMB-plugins = «thunk»; ArchiSteamFarm = «thunk»; BeatSaberModManager = «thunk»; CHOWTapeModel = «thunk»; ChowCentaur = «thunk»; ChowKick = «thunk»; ChowPhaser = «thunk»; CoinMP = «thunk»; «18783 attributes elided»}

While preparing PRs like NixOS#9753, I've had to change error messages in dozens of code paths. It would be nice if instead of EvalError("expected 'boolean' but found '%1%'", showType(v)) we could write TypeError(v, "boolean") or similar. Then, changing the error message could be a mechanical refactor with the compiler pointing out places the constructor needs to be changed, rather than the error-prone process of grepping through the codebase. Structured errors would also help prevent the "same" error from having multiple slightly different messages, and could be a first step towards error codes / an error index. This PR reworks the exception infrastructure in `libexpr` to support exception types with different constructor signatures than `BaseError`. Actually refactoring the exceptions to use structured data will come in a future PR (this one is big enough already, as it has to touch every exception in `libexpr`). The core design is in `eval-error.hh`. Generally, errors like this: state.error("'%s' is not a string", getAttrPathStr()) .debugThrow<TypeError>() are transformed like this: EvalErrorBuilder<TypeError>(state, "'%s' is not a string", getAttrPathStr()) .debugThrow()

While preparing PRs like NixOS#9753, I've had to change error messages in dozens of code paths. It would be nice if instead of EvalError("expected 'boolean' but found '%1%'", showType(v)) we could write TypeError(v, "boolean") or similar. Then, changing the error message could be a mechanical refactor with the compiler pointing out places the constructor needs to be changed, rather than the error-prone process of grepping through the codebase. Structured errors would also help prevent the "same" error from having multiple slightly different messages, and could be a first step towards error codes / an error index. This PR reworks the exception infrastructure in `libexpr` to support exception types with different constructor signatures than `BaseError`. Actually refactoring the exceptions to use structured data will come in a future PR (this one is big enough already, as it has to touch every exception in `libexpr`). The core design is in `eval-error.hh`. Generally, errors like this: state.error("'%s' is not a string", getAttrPathStr()) .debugThrow<TypeError>() are transformed like this: state.error<TypeError>("'%s' is not a string", getAttrPathStr()) .debugThrow() The type annotation has moved from `ErrorBuilder::debugThrow` to `EvalState::error`.

This fixes the opening bracket of lists/attrsets being printed in magenta, unlike the closing bracket. NixOS#9753 (comment)

Print the value in `value is X while a Y is expected` error (cherry picked from commit 5f72a97) Change-Id: Idb4bc903ae59a0f5b6fb3b1da4d47970fe0a6efe

While preparing PRs like NixOS#9753, I've had to change error messages in dozens of code paths. It would be nice if instead of EvalError("expected 'boolean' but found '%1%'", showType(v)) we could write TypeError(v, "boolean") or similar. Then, changing the error message could be a mechanical refactor with the compiler pointing out places the constructor needs to be changed, rather than the error-prone process of grepping through the codebase. Structured errors would also help prevent the "same" error from having multiple slightly different messages, and could be a first step towards error codes / an error index. This PR reworks the exception infrastructure in `libexpr` to support exception types with different constructor signatures than `BaseError`. Actually refactoring the exceptions to use structured data will come in a future PR (this one is big enough already, as it has to touch every exception in `libexpr`). The core design is in `eval-error.hh`. Generally, errors like this: state.error("'%s' is not a string", getAttrPathStr()) .debugThrow<TypeError>() are transformed like this: state.error<TypeError>("'%s' is not a string", getAttrPathStr()) .debugThrow() The type annotation has moved from `ErrorBuilder::debugThrow` to `EvalState::error`. (cherry picked from commit c6a89c1) Change-Id: Iced91ba4e00ca9e801518071fb43798936cbd05a

9999years requested review from edolstra and roberth as code owners January 12, 2024 18:04

9999years changed the title ~~Print value on type error~~ Print the value in value is X while a Y is expected error Jan 12, 2024

github-actions bot added new-cli Relating to the "nix" command with-tests Issues related to testing. PRs with tests have some priority labels Jan 12, 2024

9999years force-pushed the print-value-on-type-error branch from 04bb0d0 to 004bfaf Compare January 12, 2024 18:35

roberth reviewed Jan 13, 2024

View reviewed changes

roberth mentioned this pull request Jan 13, 2024

Print the value in error: cannot coerce messages #9754

Merged

roberth self-assigned this Jan 13, 2024

Ma27 reviewed Jan 15, 2024

View reviewed changes

9999years force-pushed the print-value-on-type-error branch from 664d1b1 to 1c1225a Compare January 20, 2024 01:01

Ma27 reviewed Jan 20, 2024

View reviewed changes

Ma27 added a commit to Ma27/nix that referenced this pull request Jan 20, 2024

libexpr: strstream -> iostream

46b05bc

Needed to fix the build with clang. See also NixOS#9753 (comment)

Ma27 mentioned this pull request Jan 20, 2024

libexpr: print value of what is attempted to be called as function #9818

Merged

9999years force-pushed the print-value-on-type-error branch from 1c1225a to 56be92f Compare January 22, 2024 16:53

9999years requested a review from roberth January 22, 2024 16:54

Print value on type error

cb7fbd4

Adds the failing value to `value is <TYPE> while a <TYPE> is expected` error messages.

9999years force-pushed the print-value-on-type-error branch from 56be92f to cb7fbd4 Compare January 22, 2024 16:56

roberth approved these changes Jan 22, 2024

View reviewed changes

roberth merged commit 5f72a97 into NixOS:master Jan 22, 2024

9999years deleted the print-value-on-type-error branch January 22, 2024 22:41

9999years mentioned this pull request Jan 23, 2024

Towards structured error classes #9834

Merged

9999years added a commit to 9999years/nix that referenced this pull request Feb 4, 2024

Don't print values in magenta

e351f5e

This fixes the opening bracket of lists/attrsets being printed in magenta, unlike the closing bracket. NixOS#9753 (comment)

9999years mentioned this pull request Feb 4, 2024

Don't print the first bracket in values in magenta in error messages #9929

Merged

9999years added a commit to 9999years/nix that referenced this pull request Feb 4, 2024

Don't print values in magenta

9646d62

This fixes the opening bracket of lists/attrsets being printed in magenta, unlike the closing bracket. NixOS#9753 (comment)

9999years mentioned this pull request Feb 5, 2024

Better support for printing large values in nix repl and error messages #9942

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Print the value in `value is X while a Y is expected` error#9753

Print the value in `value is X while a Y is expected` error#9753
roberth merged 1 commit intoNixOS:masterfrom
9999years:print-value-on-type-error

9999years commented Jan 12, 2024

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Ma27 left a comment

Uh oh!

Ma27 Jan 20, 2024

Uh oh!

9999years Jan 22, 2024

Uh oh!

roberth commented Jan 22, 2024

Uh oh!

9999years commented Jan 22, 2024

Uh oh!

roberth commented Jan 22, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

9999years commented Jan 12, 2024

Motivation

Context

Priorities

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Ma27 left a comment

Choose a reason for hiding this comment

Uh oh!

Ma27 Jan 20, 2024

Choose a reason for hiding this comment

Uh oh!

9999years Jan 22, 2024

Choose a reason for hiding this comment

Uh oh!

roberth commented Jan 22, 2024

Uh oh!

9999years commented Jan 22, 2024

Uh oh!

roberth commented Jan 22, 2024

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants