2006-07-26 18:05:15 +03:00
|
|
|
#include "attr-path.hh"
|
2012-03-05 23:04:40 +02:00
|
|
|
#include "eval-inline.hh"
|
2006-09-05 00:06:23 +03:00
|
|
|
|
|
|
|
|
|
|
|
namespace nix {
|
2006-07-26 18:05:15 +03:00
|
|
|
|
|
|
|
|
2020-06-18 14:44:40 +03:00
|
|
|
static Strings parseAttrPath(std::string_view s)
|
2013-11-18 12:21:12 +02:00
|
|
|
{
|
|
|
|
Strings res;
|
2022-02-25 17:00:00 +02:00
|
|
|
std::string cur;
|
2020-06-18 14:44:40 +03:00
|
|
|
auto i = s.begin();
|
2013-11-18 12:21:12 +02:00
|
|
|
while (i != s.end()) {
|
|
|
|
if (*i == '.') {
|
|
|
|
res.push_back(cur);
|
|
|
|
cur.clear();
|
|
|
|
} else if (*i == '"') {
|
|
|
|
++i;
|
|
|
|
while (1) {
|
|
|
|
if (i == s.end())
|
2021-06-30 00:28:43 +03:00
|
|
|
throw ParseError("missing closing quote in selection path '%1%'", s);
|
2013-11-18 12:21:12 +02:00
|
|
|
if (*i == '"') break;
|
|
|
|
cur.push_back(*i++);
|
|
|
|
}
|
|
|
|
} else
|
|
|
|
cur.push_back(*i);
|
|
|
|
++i;
|
|
|
|
}
|
|
|
|
if (!cur.empty()) res.push_back(cur);
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2020-06-18 14:44:40 +03:00
|
|
|
std::vector<Symbol> parseAttrPath(EvalState & state, std::string_view s)
|
|
|
|
{
|
|
|
|
std::vector<Symbol> res;
|
|
|
|
for (auto & a : parseAttrPath(s))
|
|
|
|
res.push_back(state.symbols.create(a));
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2022-03-04 20:31:59 +02:00
|
|
|
std::pair<Value *, PosIdx> findAlongAttrPath(EvalState & state, const std::string & attrPath,
|
2013-09-03 16:17:51 +03:00
|
|
|
Bindings & autoArgs, Value & vIn)
|
2006-07-26 18:05:15 +03:00
|
|
|
{
|
2013-11-18 12:21:12 +02:00
|
|
|
Strings tokens = parseAttrPath(attrPath);
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2013-09-03 16:17:51 +03:00
|
|
|
Value * v = &vIn;
|
2022-03-04 20:31:59 +02:00
|
|
|
PosIdx pos = noPos;
|
2013-09-02 17:29:15 +03:00
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
for (auto & attr : tokens) {
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2015-07-17 20:24:28 +03:00
|
|
|
/* Is i an index (integer) or a normal attribute name? */
|
2021-01-08 13:22:21 +02:00
|
|
|
auto attrIndex = string2Int<unsigned int>(attr);
|
2006-07-26 18:05:15 +03:00
|
|
|
|
|
|
|
/* Evaluate the expression. */
|
2013-09-03 16:17:51 +03:00
|
|
|
Value * vNew = state.allocValue();
|
|
|
|
state.autoCallFunction(autoArgs, *v, *vNew);
|
|
|
|
v = vNew;
|
2022-01-21 18:44:19 +02:00
|
|
|
state.forceValue(*v, noPos);
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2013-10-24 17:41:04 +03:00
|
|
|
/* It should evaluate to either a set or an expression,
|
|
|
|
according to what is specified in the attrPath. */
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2021-01-08 13:22:21 +02:00
|
|
|
if (!attrIndex) {
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2020-12-17 15:45:45 +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
|
|
|
state.error<TypeError>(
|
2020-04-22 02:07:07 +03:00
|
|
|
"the expression selected by the selection path '%1%' should be a set but is %2%",
|
|
|
|
attrPath,
|
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
|
|
|
showType(*v)).debugThrow();
|
2013-11-18 12:21:12 +02:00
|
|
|
if (attr.empty())
|
2020-04-22 02:07:07 +03:00
|
|
|
throw Error("empty attribute name in selection path '%1%'", attrPath);
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2013-09-03 16:17:51 +03:00
|
|
|
Bindings::iterator a = v->attrs->find(state.symbols.create(attr));
|
2022-03-03 11:50:35 +02:00
|
|
|
if (a == v->attrs->end()) {
|
|
|
|
std::set<std::string> attrNames;
|
|
|
|
for (auto & attr : *v->attrs)
|
2022-03-05 15:40:24 +02:00
|
|
|
attrNames.insert(state.symbols[attr.name]);
|
2022-03-03 11:50:35 +02:00
|
|
|
|
|
|
|
auto suggestions = Suggestions::bestMatches(attrNames, attr);
|
|
|
|
throw AttrPathNotFound(suggestions, "attribute '%1%' in selection path '%2%' not found", attr, attrPath);
|
|
|
|
}
|
2013-09-03 16:17:51 +03:00
|
|
|
v = &*a->value;
|
2022-03-04 20:31:59 +02:00
|
|
|
pos = a->pos;
|
2006-07-26 18:05:15 +03:00
|
|
|
}
|
|
|
|
|
2021-01-08 13:22:21 +02:00
|
|
|
else {
|
2006-07-26 18:05:15 +03:00
|
|
|
|
2015-07-23 23:05:09 +03: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
|
|
|
state.error<TypeError>(
|
2020-04-22 02:07:07 +03:00
|
|
|
"the expression selected by the selection path '%1%' should be a list but is %2%",
|
|
|
|
attrPath,
|
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
|
|
|
showType(*v)).debugThrow();
|
2021-01-08 13:22:21 +02:00
|
|
|
if (*attrIndex >= v->listSize())
|
|
|
|
throw AttrPathNotFound("list index %1% in selection path '%2%' is out of range", *attrIndex, attrPath);
|
2010-04-07 18:47:06 +03:00
|
|
|
|
2021-01-08 13:22:21 +02:00
|
|
|
v = v->listElems()[*attrIndex];
|
2020-02-07 15:08:24 +02:00
|
|
|
pos = noPos;
|
2006-07-26 18:05:15 +03:00
|
|
|
}
|
2013-09-02 17:29:15 +03:00
|
|
|
|
2006-07-26 18:05:15 +03:00
|
|
|
}
|
2013-09-03 16:17:51 +03:00
|
|
|
|
2020-02-07 15:08:24 +02:00
|
|
|
return {v, pos};
|
2006-07-26 18:05:15 +03:00
|
|
|
}
|
2006-09-05 00:06:23 +03:00
|
|
|
|
2013-09-02 17:29:15 +03:00
|
|
|
|
2023-04-06 14:15:50 +03:00
|
|
|
std::pair<SourcePath, uint32_t> findPackageFilename(EvalState & state, Value & v, std::string what)
|
2019-10-23 18:21:10 +03:00
|
|
|
{
|
|
|
|
Value * v2;
|
|
|
|
try {
|
|
|
|
auto dummyArgs = state.allocBindings(0);
|
2020-02-07 15:08:24 +02:00
|
|
|
v2 = findAlongAttrPath(state, "meta.position", *dummyArgs, v).first;
|
2019-10-23 18:21:10 +03:00
|
|
|
} catch (Error &) {
|
2020-02-07 15:22:01 +02:00
|
|
|
throw NoPositionInfo("package '%s' has no source location information", what);
|
2019-10-23 18:21:10 +03:00
|
|
|
}
|
|
|
|
|
2019-10-28 22:40:02 +02:00
|
|
|
// FIXME: is it possible to extract the Pos object instead of doing this
|
|
|
|
// toString + parsing?
|
2023-04-24 14:20:36 +03:00
|
|
|
NixStringContext context;
|
2023-04-06 14:15:50 +03:00
|
|
|
auto path = state.coerceToPath(noPos, *v2, context, "while evaluating the 'meta.position' attribute of a derivation");
|
2019-10-23 18:21:10 +03:00
|
|
|
|
2023-04-06 14:15:50 +03:00
|
|
|
auto fn = path.path.abs();
|
|
|
|
|
|
|
|
auto fail = [fn]() {
|
|
|
|
throw ParseError("cannot parse 'meta.position' attribute '%s'", fn);
|
|
|
|
};
|
2019-10-23 18:21:10 +03:00
|
|
|
|
|
|
|
try {
|
2023-04-06 14:15:50 +03:00
|
|
|
auto colon = fn.rfind(':');
|
|
|
|
if (colon == std::string::npos) fail();
|
|
|
|
std::string filename(fn, 0, colon);
|
|
|
|
auto lineno = std::stoi(std::string(fn, colon + 1, std::string::npos));
|
2023-10-18 16:32:31 +03:00
|
|
|
return {SourcePath{path.accessor, CanonPath(fn.substr(0, colon))}, lineno};
|
2019-10-23 18:21:10 +03:00
|
|
|
} catch (std::invalid_argument & e) {
|
2023-04-06 14:15:50 +03:00
|
|
|
fail();
|
|
|
|
abort();
|
2019-10-23 18:21:10 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2006-09-05 00:06:23 +03:00
|
|
|
}
|