2012-07-18 21:59:03 +03:00
|
|
|
#pragma once
|
2023-04-01 06:18:41 +03:00
|
|
|
///@file
|
2012-02-04 15:50:25 +02:00
|
|
|
|
2023-12-07 02:03:01 +02:00
|
|
|
#include "print.hh"
|
2012-02-04 15:50:25 +02:00
|
|
|
#include "eval.hh"
|
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 "eval-error.hh"
|
2012-02-04 15:50:25 +02:00
|
|
|
|
|
|
|
namespace nix {
|
|
|
|
|
2023-04-07 16:55:28 +03:00
|
|
|
/**
|
|
|
|
* Note: Various places expect the allocated memory to be zeroed.
|
|
|
|
*/
|
2021-12-28 20:18:17 +02:00
|
|
|
[[gnu::always_inline]]
|
|
|
|
inline void * allocBytes(size_t n)
|
|
|
|
{
|
|
|
|
void * p;
|
|
|
|
#if HAVE_BOEHMGC
|
|
|
|
p = GC_MALLOC(n);
|
|
|
|
#else
|
|
|
|
p = calloc(n, 1);
|
|
|
|
#endif
|
|
|
|
if (!p) throw std::bad_alloc();
|
|
|
|
return p;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
[[gnu::always_inline]]
|
|
|
|
Value * EvalState::allocValue()
|
|
|
|
{
|
2022-01-05 02:48:26 +02:00
|
|
|
#if HAVE_BOEHMGC
|
2021-12-28 20:18:17 +02:00
|
|
|
/* We use the boehm batch allocator to speed up allocations of Values (of which there are many).
|
|
|
|
GC_malloc_many returns a linked list of objects of the given size, where the first word
|
|
|
|
of each object is also the pointer to the next object in the list. This also means that we
|
|
|
|
have to explicitly clear the first word of every object we take. */
|
|
|
|
if (!*valueAllocCache) {
|
|
|
|
*valueAllocCache = GC_malloc_many(sizeof(Value));
|
|
|
|
if (!*valueAllocCache) throw std::bad_alloc();
|
|
|
|
}
|
|
|
|
|
|
|
|
/* GC_NEXT is a convenience macro for accessing the first word of an object.
|
|
|
|
Take the first list item, advance the list to the next item, and clear the next pointer. */
|
|
|
|
void * p = *valueAllocCache;
|
|
|
|
*valueAllocCache = GC_NEXT(p);
|
|
|
|
GC_NEXT(p) = nullptr;
|
2022-01-05 02:48:26 +02:00
|
|
|
#else
|
|
|
|
void * p = allocBytes(sizeof(Value));
|
|
|
|
#endif
|
2021-12-28 20:18:17 +02:00
|
|
|
|
|
|
|
nrValues++;
|
|
|
|
return (Value *) p;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
[[gnu::always_inline]]
|
|
|
|
Env & EvalState::allocEnv(size_t size)
|
|
|
|
{
|
|
|
|
nrEnvs++;
|
|
|
|
nrValuesInEnvs += size;
|
|
|
|
|
|
|
|
Env * env;
|
|
|
|
|
2022-01-05 02:48:26 +02:00
|
|
|
#if HAVE_BOEHMGC
|
|
|
|
if (size == 1) {
|
2021-12-28 20:18:17 +02:00
|
|
|
/* see allocValue for explanations. */
|
|
|
|
if (!*env1AllocCache) {
|
|
|
|
*env1AllocCache = GC_malloc_many(sizeof(Env) + sizeof(Value *));
|
|
|
|
if (!*env1AllocCache) throw std::bad_alloc();
|
|
|
|
}
|
|
|
|
|
|
|
|
void * p = *env1AllocCache;
|
|
|
|
*env1AllocCache = GC_NEXT(p);
|
|
|
|
GC_NEXT(p) = nullptr;
|
|
|
|
env = (Env *) p;
|
2022-01-05 02:48:26 +02:00
|
|
|
} else
|
|
|
|
#endif
|
|
|
|
env = (Env *) allocBytes(sizeof(Env) + size * sizeof(Value *));
|
2021-12-28 20:18:17 +02:00
|
|
|
|
|
|
|
/* We assume that env->values has been cleared by the allocator; maybeThunk() and lookupVar fromWith expect this. */
|
|
|
|
|
|
|
|
return *env;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2023-12-11 16:54:16 +02:00
|
|
|
[[gnu::always_inline]]
|
2022-03-04 20:31:59 +02:00
|
|
|
void EvalState::forceValue(Value & v, const PosIdx pos)
|
2012-02-04 15:50:25 +02:00
|
|
|
{
|
2020-12-12 03:15:11 +02:00
|
|
|
if (v.isThunk()) {
|
2024-03-25 19:20:18 +02:00
|
|
|
Env * env = v.payload.thunk.env;
|
|
|
|
Expr * expr = v.payload.thunk.expr;
|
2012-02-04 15:50:25 +02:00
|
|
|
try {
|
2020-12-18 15:38:49 +02:00
|
|
|
v.mkBlackhole();
|
2012-02-04 15:50:25 +02:00
|
|
|
//checkInterrupt();
|
2013-03-14 18:21:13 +02:00
|
|
|
expr->eval(*this, *env, v);
|
2017-06-20 13:11:22 +03:00
|
|
|
} catch (...) {
|
2020-12-18 15:38:49 +02:00
|
|
|
v.mkThunk(env, expr);
|
2023-12-11 17:23:08 +02:00
|
|
|
tryFixupBlackHolePos(v, pos);
|
2012-02-04 15:50:25 +02:00
|
|
|
throw;
|
|
|
|
}
|
|
|
|
}
|
2023-12-11 17:23:08 +02:00
|
|
|
else if (v.isApp())
|
2024-03-25 19:20:18 +02:00
|
|
|
callFunction(*v.payload.app.left, *v.payload.app.right, v, pos);
|
2012-02-04 15:50:25 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-12-28 20:18:17 +02:00
|
|
|
[[gnu::always_inline]]
|
2023-01-19 14:23:04 +02:00
|
|
|
inline void EvalState::forceAttrs(Value & v, const PosIdx pos, std::string_view errorCtx)
|
2014-04-04 20:11:40 +03:00
|
|
|
{
|
2023-01-19 14:23:04 +02:00
|
|
|
forceAttrs(v, [&]() { return pos; }, errorCtx);
|
2022-02-04 01:31:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
template <typename Callable>
|
2021-12-28 20:18:17 +02:00
|
|
|
[[gnu::always_inline]]
|
2023-01-19 14:23:04 +02:00
|
|
|
inline void EvalState::forceAttrs(Value & v, Callable getPos, std::string_view errorCtx)
|
2022-02-04 01:31:33 +02:00
|
|
|
{
|
2023-12-07 20:01:42 +02:00
|
|
|
PosIdx pos = getPos();
|
|
|
|
forceValue(v, pos);
|
2023-01-19 14:23:04 +02:00
|
|
|
if (v.type() != nAttrs) {
|
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
|
|
|
error<TypeError>(
|
|
|
|
"expected a set but found %1%: %2%",
|
|
|
|
showType(v),
|
|
|
|
ValuePrinter(*this, v, errorPrintOptions)
|
|
|
|
).withTrace(pos, errorCtx).debugThrow();
|
2023-01-19 14:23:04 +02:00
|
|
|
}
|
2014-04-04 20:11:40 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2021-12-28 20:18:17 +02:00
|
|
|
[[gnu::always_inline]]
|
2023-01-19 14:23:04 +02:00
|
|
|
inline void EvalState::forceList(Value & v, const PosIdx pos, std::string_view errorCtx)
|
2014-04-04 20:05:36 +03:00
|
|
|
{
|
2023-12-07 20:01:42 +02:00
|
|
|
forceValue(v, pos);
|
2023-01-19 14:23:04 +02:00
|
|
|
if (!v.isList()) {
|
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
|
|
|
error<TypeError>(
|
|
|
|
"expected a list but found %1%: %2%",
|
|
|
|
showType(v),
|
|
|
|
ValuePrinter(*this, v, errorPrintOptions)
|
|
|
|
).withTrace(pos, errorCtx).debugThrow();
|
2023-01-19 14:23:04 +02:00
|
|
|
}
|
2014-04-04 20:05:36 +03:00
|
|
|
}
|
|
|
|
|
2018-06-11 16:58:19 +03:00
|
|
|
|
2012-02-04 15:50:25 +02:00
|
|
|
}
|