2022-03-21 12:31:01 +02:00
# include "primops.hh"
# include "store-api.hh"
2022-03-18 17:35:45 +02:00
# include "realisation.hh"
2022-03-22 22:14:58 +02:00
# include "make-content-addressed.hh"
2022-03-22 23:47:33 +02:00
# include "url.hh"
2022-03-21 12:31:01 +02:00
namespace nix {
2023-06-05 13:35:03 +03:00
/**
* Handler for the content addressed case .
*
2023-06-07 13:47:18 +03:00
* @ param state Evaluator state and store to write to .
* @ param fromStore Store containing the path to rewrite .
* @ param fromPath Source path to be rewritten .
* @ param toPathMaybe Path to write the rewritten path to . If empty , the error shows the actual path .
* @ param v Return ` Value `
2023-06-05 13:35:03 +03:00
*/
static void runFetchClosureWithRewrite ( EvalState & state , const PosIdx pos , Store & fromStore , const StorePath & fromPath , const std : : optional < StorePath > & toPathMaybe , Value & v ) {
// establish toPath or throw
if ( ! toPathMaybe | | ! state . store - > isValidPath ( * toPathMaybe ) ) {
auto rewrittenPath = makeContentAddressed ( fromStore , * state . store , fromPath ) ;
if ( toPathMaybe & & * toPathMaybe ! = rewrittenPath )
throw Error ( {
. msg = hintfmt ( " rewriting '%s' to content-addressed form yielded '%s', while '%s' was expected " ,
state . store - > printStorePath ( fromPath ) ,
state . store - > printStorePath ( rewrittenPath ) ,
state . store - > printStorePath ( * toPathMaybe ) ) ,
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
. pos = state . positions [ pos ]
2023-06-05 13:35:03 +03:00
} ) ;
if ( ! toPathMaybe )
throw Error ( {
. msg = hintfmt (
2023-06-07 13:47:18 +03:00
" rewriting '%s' to content-addressed form yielded '%s' \n "
" Use this value for the 'toPath' attribute passed to 'fetchClosure' " ,
2023-06-05 13:35:03 +03:00
state . store - > printStorePath ( fromPath ) ,
state . store - > printStorePath ( rewrittenPath ) ) ,
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
. pos = state . positions [ pos ]
2023-06-05 13:35:03 +03:00
} ) ;
}
auto toPath = * toPathMaybe ;
// check and return
auto resultInfo = state . store - > queryPathInfo ( toPath ) ;
if ( ! resultInfo - > isContentAddressed ( * state . store ) ) {
// We don't perform the rewriting when outPath already exists, as an optimisation.
// However, we can quickly detect a mistake if the toPath is input addressed.
throw Error ( {
2023-06-07 13:47:18 +03:00
. msg = hintfmt (
" The 'toPath' value '%s' is input-addressed, so it can't possibly be the result of rewriting to a content-addressed path. \n \n "
" Set 'toPath' to an empty string to make Nix report the correct content-addressed path. " ,
2023-06-05 13:35:03 +03:00
state . store - > printStorePath ( toPath ) ) ,
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
. pos = state . positions [ pos ]
2023-06-05 13:35:03 +03:00
} ) ;
}
state . mkStorePathString ( toPath , v ) ;
}
/**
* Fetch the closure and make sure it ' s content addressed .
*/
static void runFetchClosureWithContentAddressedPath ( EvalState & state , const PosIdx pos , Store & fromStore , const StorePath & fromPath , Value & v ) {
if ( ! state . store - > isValidPath ( fromPath ) )
copyClosure ( fromStore , * state . store , RealisedPath : : Set { fromPath } ) ;
auto info = state . store - > queryPathInfo ( fromPath ) ;
if ( ! info - > isContentAddressed ( * state . store ) ) {
throw Error ( {
2023-06-07 13:47:18 +03:00
. msg = hintfmt (
" The 'fromPath' value '%s' is input-addressed, but 'inputAddressed' is set to 'false' (default). \n \n "
2023-07-07 12:00:40 +03:00
" If you do intend to fetch an input-addressed store path, add \n \n "
" inputAddressed = true; \n \n "
" to the 'fetchClosure' arguments. \n \n "
" Note that to ensure authenticity input-addressed store paths, users must configure a trusted binary cache public key on their systems. This is not needed for content-addressed paths. " ,
2023-06-05 13:35:03 +03:00
state . store - > printStorePath ( fromPath ) ) ,
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
. pos = state . positions [ pos ]
2023-06-05 13:35:03 +03:00
} ) ;
}
state . mkStorePathString ( fromPath , v ) ;
}
/**
* Fetch the closure and make sure it ' s input addressed .
*/
static void runFetchClosureWithInputAddressedPath ( EvalState & state , const PosIdx pos , Store & fromStore , const StorePath & fromPath , Value & v ) {
if ( ! state . store - > isValidPath ( fromPath ) )
copyClosure ( fromStore , * state . store , RealisedPath : : Set { fromPath } ) ;
auto info = state . store - > queryPathInfo ( fromPath ) ;
if ( info - > isContentAddressed ( * state . store ) ) {
throw Error ( {
2023-06-07 13:47:18 +03:00
. msg = hintfmt (
" The store object referred to by 'fromPath' at '%s' is not input-addressed, but 'inputAddressed' is set to 'true'. \n \n "
" Remove the 'inputAddressed' attribute (it defaults to 'false') to expect 'fromPath' to be content-addressed " ,
2023-06-05 13:35:03 +03:00
state . store - > printStorePath ( fromPath ) ) ,
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
. pos = state . positions [ pos ]
2023-06-05 13:35:03 +03:00
} ) ;
}
state . mkStorePathString ( fromPath , v ) ;
}
2023-06-05 13:55:58 +03:00
typedef std : : optional < StorePath > StorePathOrGap ;
2022-03-04 20:31:59 +02:00
static void prim_fetchClosure ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2022-03-21 12:31:01 +02:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the argument passed to builtins.fetchClosure " ) ;
2022-03-21 12:31:01 +02:00
2022-03-21 15:34:45 +02:00
std : : optional < std : : string > fromStoreUrl ;
std : : optional < StorePath > fromPath ;
2023-06-05 13:55:58 +03:00
std : : optional < StorePathOrGap > toPath ;
2023-05-19 17:25:23 +03:00
std : : optional < bool > inputAddressedMaybe ;
2022-03-21 12:31:01 +02:00
for ( auto & attr : * args [ 0 ] - > attrs ) {
2022-03-05 15:40:24 +02:00
const auto & attrName = state . symbols [ attr . name ] ;
2023-05-19 10:49:18 +03:00
auto attrHint = [ & ] ( ) - > std : : string {
return " while evaluating the ' " + attrName + " ' attribute passed to builtins.fetchClosure " ;
} ;
2022-03-05 15:40:24 +02:00
if ( attrName = = " fromPath " ) {
Use `std::set<StringContextElem>` not `PathSet` for string contexts
Motivation
`PathSet` is not correct because string contexts have other forms
(`Built` and `DrvDeep`) that are not rendered as plain store paths.
Instead of wrongly using `PathSet`, or "stringly typed" using
`StringSet`, use `std::std<StringContextElem>`.
-----
In support of this change, `NixStringContext` is now defined as
`std::std<StringContextElem>` not `std:vector<StringContextElem>`. The
old definition was just used by a `getContext` method which was only
used by the eval cache. It can be deleted altogether since the types are
now unified and the preexisting `copyContext` function already suffices.
Summarizing the previous paragraph:
Old:
- `value/context.hh`: `NixStringContext = std::vector<StringContextElem>`
- `value.hh`: `NixStringContext Value::getContext(...)`
- `value.hh`: `copyContext(...)`
New:
- `value/context.hh`: `NixStringContext = std::set<StringContextElem>`
- `value.hh`: `copyContext(...)`
----
The string representation of string context elements no longer contains
the store dir. The diff of `src/libexpr/tests/value/context.cc` should
make clear what the new representation is, so we recommend reviewing
that file first. This was done for two reasons:
Less API churn:
`Value::mkString` and friends did not take a `Store` before. But if
`NixStringContextElem::{parse, to_string}` *do* take a store (as they
did before), then we cannot have the `Value` functions use them (in
order to work with the fully-structured `NixStringContext`) without
adding that argument.
That would have been a lot of churn of threading the store, and this
diff is already large enough, so the easier and less invasive thing to
do was simply make the element `parse` and `to_string` functions not
take the `Store` reference, and the easiest way to do that was to simply
drop the store dir.
Space usage:
Dropping the `/nix/store/` (or similar) from the internal representation
will safe space in the heap of the Nix programming being interpreted. If
the heap contains many strings with non-trivial contexts, the saving
could add up to something significant.
----
The eval cache version is bumped.
The eval cache serialization uses `NixStringContextElem::{parse,
to_string}`, and since those functions are changed per the above, that
means the on-disk representation is also changed.
This is simply done by changing the name of the used for the eval cache
from `eval-cache-v4` to eval-cache-v5`.
----
To avoid some duplication `EvalCache::mkPathString` is added to abstract
over the simple case of turning a store path to a string with just that
string in the context.
Context
This PR picks up where #7543 left off. That one introduced the fully
structured `NixStringContextElem` data type, but kept `PathSet context`
as an awkward middle ground between internal `char[][]` interpreter heap
string contexts and `NixStringContext` fully parsed string contexts.
The infelicity of `PathSet context` was specifically called out during
Nix team group review, but it was agreeing that fixing it could be left
as future work. This is that future work.
A possible follow-up step would be to get rid of the `char[][]`
evaluator heap representation, too, but it is not yet clear how to do
that. To use `NixStringContextElem` there we would need to get the STL
containers to GC pointers in the GC build, and I am not sure how to do
that.
----
PR #7543 effectively is writing the inverse of a `mkPathString`,
`mkOutputString`, and one more such function for the `DrvDeep` case. I
would like that PR to have property tests ensuring it is actually the
inverse as expected.
This PR sets things up nicely so that reworking that PR to be in that
more elegant and better tested way is possible.
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
2023-01-29 03:31:10 +02:00
NixStringContext context ;
2023-05-19 10:49:18 +03:00
fromPath = state . coerceToStorePath ( attr . pos , * attr . value , context , attrHint ( ) ) ;
2022-03-21 12:31:01 +02:00
}
2022-03-05 15:40:24 +02:00
else if ( attrName = = " toPath " ) {
2022-03-04 20:31:59 +02:00
state . forceValue ( * attr . value , attr . pos ) ;
2023-09-26 04:30:41 +03:00
bool isEmptyString = attr . value - > type ( ) = = nString & & attr . value - > string_view ( ) = = " " ;
2023-06-05 13:55:58 +03:00
if ( isEmptyString ) {
toPath = StorePathOrGap { } ;
}
else {
Use `std::set<StringContextElem>` not `PathSet` for string contexts
Motivation
`PathSet` is not correct because string contexts have other forms
(`Built` and `DrvDeep`) that are not rendered as plain store paths.
Instead of wrongly using `PathSet`, or "stringly typed" using
`StringSet`, use `std::std<StringContextElem>`.
-----
In support of this change, `NixStringContext` is now defined as
`std::std<StringContextElem>` not `std:vector<StringContextElem>`. The
old definition was just used by a `getContext` method which was only
used by the eval cache. It can be deleted altogether since the types are
now unified and the preexisting `copyContext` function already suffices.
Summarizing the previous paragraph:
Old:
- `value/context.hh`: `NixStringContext = std::vector<StringContextElem>`
- `value.hh`: `NixStringContext Value::getContext(...)`
- `value.hh`: `copyContext(...)`
New:
- `value/context.hh`: `NixStringContext = std::set<StringContextElem>`
- `value.hh`: `copyContext(...)`
----
The string representation of string context elements no longer contains
the store dir. The diff of `src/libexpr/tests/value/context.cc` should
make clear what the new representation is, so we recommend reviewing
that file first. This was done for two reasons:
Less API churn:
`Value::mkString` and friends did not take a `Store` before. But if
`NixStringContextElem::{parse, to_string}` *do* take a store (as they
did before), then we cannot have the `Value` functions use them (in
order to work with the fully-structured `NixStringContext`) without
adding that argument.
That would have been a lot of churn of threading the store, and this
diff is already large enough, so the easier and less invasive thing to
do was simply make the element `parse` and `to_string` functions not
take the `Store` reference, and the easiest way to do that was to simply
drop the store dir.
Space usage:
Dropping the `/nix/store/` (or similar) from the internal representation
will safe space in the heap of the Nix programming being interpreted. If
the heap contains many strings with non-trivial contexts, the saving
could add up to something significant.
----
The eval cache version is bumped.
The eval cache serialization uses `NixStringContextElem::{parse,
to_string}`, and since those functions are changed per the above, that
means the on-disk representation is also changed.
This is simply done by changing the name of the used for the eval cache
from `eval-cache-v4` to eval-cache-v5`.
----
To avoid some duplication `EvalCache::mkPathString` is added to abstract
over the simple case of turning a store path to a string with just that
string in the context.
Context
This PR picks up where #7543 left off. That one introduced the fully
structured `NixStringContextElem` data type, but kept `PathSet context`
as an awkward middle ground between internal `char[][]` interpreter heap
string contexts and `NixStringContext` fully parsed string contexts.
The infelicity of `PathSet context` was specifically called out during
Nix team group review, but it was agreeing that fixing it could be left
as future work. This is that future work.
A possible follow-up step would be to get rid of the `char[][]`
evaluator heap representation, too, but it is not yet clear how to do
that. To use `NixStringContextElem` there we would need to get the STL
containers to GC pointers in the GC build, and I am not sure how to do
that.
----
PR #7543 effectively is writing the inverse of a `mkPathString`,
`mkOutputString`, and one more such function for the `DrvDeep` case. I
would like that PR to have property tests ensuring it is actually the
inverse as expected.
This PR sets things up nicely so that reworking that PR to be in that
more elegant and better tested way is possible.
Co-authored-by: Théophane Hufschmitt <7226587+thufschmitt@users.noreply.github.com>
2023-01-29 03:31:10 +02:00
NixStringContext context ;
2023-05-19 10:49:18 +03:00
toPath = state . coerceToStorePath ( attr . pos , * attr . value , context , attrHint ( ) ) ;
2022-03-22 22:14:58 +02:00
}
}
2022-03-05 15:40:24 +02:00
else if ( attrName = = " fromStore " )
2023-01-19 14:23:04 +02:00
fromStoreUrl = state . forceStringNoCtx ( * attr . value , attr . pos ,
2023-05-19 10:49:18 +03:00
attrHint ( ) ) ;
2022-03-21 12:31:01 +02:00
2023-05-19 11:48:53 +03:00
else if ( attrName = = " inputAddressed " )
2023-05-19 17:25:23 +03:00
inputAddressedMaybe = state . forceBool ( * attr . value , attr . pos , attrHint ( ) ) ;
2023-05-19 11:48:53 +03:00
2022-03-21 12:31:01 +02:00
else
throw Error ( {
2022-03-05 15:40:24 +02:00
. msg = hintfmt ( " attribute '%s' isn't supported in call to 'fetchClosure' " , attrName ) ,
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
. pos = state . positions [ pos ]
2022-03-21 12:31:01 +02:00
} ) ;
}
2022-03-21 15:34:45 +02:00
if ( ! fromPath )
2022-03-21 12:31:01 +02:00
throw Error ( {
2022-03-21 15:34:45 +02:00
. msg = hintfmt ( " attribute '%s' is missing in call to 'fetchClosure' " , " fromPath " ) ,
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
. pos = state . positions [ pos ]
2022-03-21 12:31:01 +02:00
} ) ;
2023-05-19 17:25:23 +03:00
bool inputAddressed = inputAddressedMaybe . value_or ( false ) ;
2023-05-19 11:48:53 +03:00
if ( inputAddressed ) {
2023-06-05 12:11:53 +03:00
if ( toPath )
2023-05-19 11:48:53 +03:00
throw Error ( {
2023-06-05 12:11:53 +03:00
. msg = hintfmt ( " attribute '%s' is set to true, but '%s' is also set. Please remove one of them " ,
2023-05-19 11:48:53 +03:00
" inputAddressed " ,
2023-06-05 12:11:53 +03:00
" toPath " ) ,
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
. pos = state . positions [ pos ]
2023-05-19 11:48:53 +03:00
} ) ;
}
2022-03-21 15:34:45 +02:00
if ( ! fromStoreUrl )
2022-03-21 12:31:01 +02:00
throw Error ( {
2022-03-21 15:34:45 +02:00
. msg = hintfmt ( " attribute '%s' is missing in call to 'fetchClosure' " , " fromStore " ) ,
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
. pos = state . positions [ pos ]
2022-03-21 12:31:01 +02:00
} ) ;
2022-03-22 23:47:33 +02:00
auto parsedURL = parseURL ( * fromStoreUrl ) ;
2022-03-23 00:19:21 +02:00
if ( parsedURL . scheme ! = " http " & &
parsedURL . scheme ! = " https " & &
! ( getEnv ( " _NIX_IN_TEST " ) . has_value ( ) & & parsedURL . scheme = = " file " ) )
2022-03-22 23:47:33 +02:00
throw Error ( {
. msg = hintfmt ( " 'fetchClosure' only supports http:// and https:// stores " ) ,
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
. pos = state . positions [ pos ]
2022-03-22 23:47:33 +02:00
} ) ;
2022-04-06 12:52:51 +03:00
if ( ! parsedURL . query . empty ( ) )
throw Error ( {
. msg = hintfmt ( " 'fetchClosure' does not support URL query parameters (in '%s') " , * fromStoreUrl ) ,
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
. pos = state . positions [ pos ]
2022-04-06 12:52:51 +03:00
} ) ;
2022-03-22 23:47:33 +02:00
auto fromStore = openStore ( parsedURL . to_string ( ) ) ;
2022-03-21 12:31:01 +02:00
2023-06-05 13:55:58 +03:00
if ( toPath )
runFetchClosureWithRewrite ( state , pos , * fromStore , * fromPath , * toPath , v ) ;
2023-06-05 13:35:03 +03:00
else if ( inputAddressed )
runFetchClosureWithInputAddressedPath ( state , pos , * fromStore , * fromPath , v ) ;
else
runFetchClosureWithContentAddressedPath ( state , pos , * fromStore , * fromPath , v ) ;
2022-03-21 12:31:01 +02:00
}
static RegisterPrimOp primop_fetchClosure ( {
. name = " __fetchClosure " ,
. args = { " args " } ,
. doc = R " (
2023-07-07 12:40:40 +03:00
Fetch a store path [ closure ] ( @ docroot @ / glossary . md # gloss - closure ) from a binary cache , and return the store path as a string with context .
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
This function can be invoked in three ways , that we will discuss in order of preference .
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
* * Fetch a content - addressed store path * *
2023-06-05 17:25:22 +03:00
2023-07-07 12:00:40 +03:00
Example :
2023-06-07 13:47:18 +03:00
2023-07-07 12:40:40 +03:00
` ` ` nix
builtins . fetchClosure {
fromStore = " https://cache.nixos.org " ;
fromPath = / nix / store / ldbhlwhh39wha58rm61bkiiwm6j7211j - git - 2.33 .1 ;
}
` ` `
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
This is the simplest invocation , and it does not require the user of the expression to configure [ ` trusted - public - keys ` ] ( @ docroot @ / command - ref / conf - file . md # conf - trusted - public - keys ) to ensure their authenticity .
2022-03-23 00:31:48 +02:00
2023-07-07 12:40:40 +03:00
If your store path is [ input addressed ] ( @ docroot @ / glossary . md # gloss - input - addressed - store - object ) instead of content addressed , consider the other two invocations .
2023-06-07 13:47:18 +03:00
2023-07-07 12:40:40 +03:00
* * Fetch any store path and rewrite it to a fully content - addressed store path * *
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
Example :
` ` ` nix
builtins . fetchClosure {
fromStore = " https://cache.nixos.org " ;
fromPath = / nix / store / r2jd6ygnmirm2g803mksqqjm4y39yi6i - git - 2.33 .1 ;
toPath = / nix / store / ldbhlwhh39wha58rm61bkiiwm6j7211j - git - 2.33 .1 ;
}
` ` `
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
This example fetches ` / nix / store / r2jd . . . ` from the specified binary cache ,
2022-03-23 00:31:48 +02:00
and rewrites it into the content - addressed store path
` / nix / store / ldbh . . . ` .
2023-07-07 12:40:40 +03:00
Like the previous example , no extra configuration or privileges are required .
2022-03-23 00:31:48 +02:00
To find out the correct value for ` toPath ` given a ` fromPath ` ,
2023-06-07 13:47:18 +03:00
use [ ` nix store make - content - addressed ` ] ( @ docroot @ / command - ref / new - cli / nix3 - store - make - content - addressed . md ) :
2022-03-23 00:31:48 +02:00
` ` ` console
2022-03-23 00:40:04 +02:00
# nix store make-content-addressed --from https: //cache.nixos.org /nix/store/r2jd6ygnmirm2g803mksqqjm4y39yi6i-git-2.33.1
2022-03-23 00:31:48 +02:00
rewrote ' / nix / store / r2jd6ygnmirm2g803mksqqjm4y39yi6i - git - 2.33 .1 ' to ' / nix / store / ldbhlwhh39wha58rm61bkiiwm6j7211j - git - 2.33 .1 '
` ` `
2023-07-07 12:00:40 +03:00
Alternatively , set ` toPath = " " ` and find the correct ` toPath ` in the error message .
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
* * Fetch an input - addressed store path as is * *
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
Example :
` ` ` nix
builtins . fetchClosure {
fromStore = " https://cache.nixos.org " ;
fromPath = / nix / store / r2jd6ygnmirm2g803mksqqjm4y39yi6i - git - 2.33 .1 ;
inputAddressed = true ;
}
` ` `
2023-06-05 17:25:22 +03:00
2023-07-07 12:40:40 +03:00
It is possible to fetch an [ input - addressed store path ] ( @ docroot @ / glossary . md # gloss - input - addressed - store - object ) and return it as is .
However , this is the least preferred way of invoking ` fetchClosure ` , because it requires that the input - addressed paths are trusted by the Nix configuration .
2023-06-05 17:25:22 +03:00
* * ` builtins . storePath ` * *
2023-07-07 12:40:40 +03:00
` fetchClosure ` is similar to [ ` builtins . storePath ` ] ( # builtins - storePath ) in that it allows you to use a previously built store path in a Nix expression .
However , ` fetchClosure ` is more reproducible because it specifies a binary cache from which the path can be fetched .
2023-07-07 12:00:40 +03:00
Also , using content - addressed store paths does not require users to configure [ ` trusted - public - keys ` ] ( @ docroot @ / command - ref / conf - file . md # conf - trusted - public - keys ) to ensure their authenticity .
2022-03-21 12:31:01 +02:00
) " ,
. fun = prim_fetchClosure ,
2022-03-25 15:04:18 +02:00
. experimentalFeature = Xp : : FetchClosure ,
2022-03-21 12:31:01 +02:00
} ) ;
}
