nix-super/src/libexpr/json-to-value.hh

#pragma once
///@file

#include "error.hh"

#include <string>

namespace nix {

class EvalState;
struct Value;

MakeError(JSONParseError, Error);

void parseJSON(EvalState & state, const std::string_view & s, Value & v);

}
Add builtin function ‘fromJSON’ Fixes #294. 2014-07-04 14:34:15 +03:00			`#pragma once`
Ensure all headers have `#pragma once` and are in API docs `///@file` makes them show up in the internal API dos. A tiny few were missing `#pragma once`. 2023-04-01 06:18:41 +03:00			`///@file`
Add builtin function ‘fromJSON’ Fixes #294. 2014-07-04 14:34:15 +03:00
libexpr: Support structured error classes 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`. 2024-01-23 03:08:29 +02:00			`#include "error.hh"`
Add builtin function ‘fromJSON’ Fixes #294. 2014-07-04 14:34:15 +03:00
			`#include <string>`

			`namespace nix {`

libexpr: Support structured error classes 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`. 2024-01-23 03:08:29 +02:00			`class EvalState;`
			`struct Value;`

			`MakeError(JSONParseError, Error);`
Add builtin function ‘fromJSON’ Fixes #294. 2014-07-04 14:34:15 +03:00
return string_views from forceString* once a string has been forced we already have dynamic storage allocated for it, so we can easily reuse that storage instead of copying. 2022-01-21 15:44:00 +02:00			`void parseJSON(EvalState & state, const std::string_view & s, Value & v);`
Add builtin function ‘fromJSON’ Fixes #294. 2014-07-04 14:34:15 +03:00
			`}`