mirror of
https://github.com/privatevoid-net/nix-super.git
synced 2024-11-10 08:16:15 +02:00
No description
c6a89c1a16
While preparing PRs like #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`. |
||
|---|---|---|
| .github | ||
| config | ||
| contrib | ||
| dep-patches | ||
| doc | ||
| m4 | ||
| maintainers | ||
| misc | ||
| mk | ||
| perl | ||
| scripts | ||
| src | ||
| tests | ||
| .clang-format | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitignore | ||
| .version | ||
| configure.ac | ||
| CONTRIBUTING.md | ||
| COPYING | ||
| default.nix | ||
| docker.nix | ||
| flake.lock | ||
| flake.nix | ||
| local.mk | ||
| Makefile | ||
| Makefile.config.in | ||
| package.nix | ||
| precompiled-headers.h | ||
| README.md | ||
| shell.nix | ||
Nix
Nix is a powerful package manager for Linux and other Unix systems that makes package management reliable and reproducible. Please refer to the Nix manual for more details.
Installation and first steps
Visit nix.dev for installation instructions and beginner tutorials.
Full reference documentation can be found in the Nix manual.
Building And Developing
See our Hacking guide in our manual for instruction on how to set up a development environment and build Nix from source.
Contributing
Check the contributing guide if you want to get involved with developing Nix.
Additional Resources
License
Nix is released under the LGPL v2.1.