Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
# include "archive.hh"
# include "derivations.hh"
2023-05-12 01:01:41 +03:00
# include "downstream-placeholder.hh"
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
# include "eval-inline.hh"
2004-08-04 13:59:20 +03:00
# include "eval.hh"
2023-07-31 16:19:19 +03:00
# include "eval-settings.hh"
2023-11-20 14:38:52 +02:00
# include "gc-small-vector.hh"
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
# include "json-to-value.hh"
# include "names.hh"
2023-03-17 16:51:08 +02:00
# include "path-references.hh"
2006-11-30 19:43:04 +02:00
# include "store-api.hh"
2006-09-05 00:06:23 +03:00
# include "util.hh"
2023-10-25 07:43:36 +03:00
# include "processes.hh"
2013-11-19 01:03:11 +02:00
# include "value-to-json.hh"
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
# include "value-to-xml.hh"
2016-04-13 12:15:45 +03:00
# include "primops.hh"
2023-12-18 23:14:42 +02:00
# include "fetch-to-store.hh"
2006-09-05 00:06:23 +03:00
2022-01-02 01:41:21 +02:00
# include <boost/container/small_vector.hpp>
2022-11-16 17:49:49 +02:00
# include <nlohmann/json.hpp>
2022-01-02 01:41:21 +02:00
2007-01-15 10:54:51 +02:00
# include <sys/types.h>
# include <sys/stat.h>
# include <unistd.h>
2006-09-05 00:06:23 +03:00
# include <algorithm>
2010-03-30 12:22:33 +03:00
# include <cstring>
Remove 100s of CPU time (10%) from build times (1465s -> 1302s)
Result's from Mic92's framework 13th Gen Intel Core i7-1360P:
Before: 3595.92s user 183.01s system 1360% cpu 4:37.74 total
After: 3486.07s user 168.93s system 1354% cpu 4:29.79 total
I saw that boost/lexical_cast was costing about 100s in CPU time on our
compiles. We can fix this trivially by doing explicit template
instantiation in exactly one place and eliminating all other includes of
it, which is a code improvement anyway by hiding the boost.
Before:
```
lix/lix2 » ClangBuildAnalyzer --analyze buildtimeold.bin
Analyzing build trace from 'buildtimeold.bin'...
**** Time summary:
Compilation (551 times):
Parsing (frontend): 1465.3 s
Codegen & opts (backend): 1110.9 s
<snip>
**** Expensive headers:
178153 ms: ../src/libcmd/installable-value.hh (included 52 times, avg 3426 ms), included via:
40x: command.hh
5x: command-installable-value.hh
3x: installable-flake.hh
2x: <direct include>
2x: installable-attr-path.hh
176217 ms: ../src/libutil/error.hh (included 246 times, avg 716 ms), included via:
36x: command.hh installable-value.hh installables.hh derived-path.hh config.hh experimental-features.hh
12x: globals.hh config.hh experimental-features.hh
11x: file-system.hh file-descriptor.hh
6x: serialise.hh strings.hh
6x: <direct include>
6x: archive.hh serialise.hh strings.hh
...
173243 ms: ../src/libstore/store-api.hh (included 152 times, avg 1139 ms), included via:
55x: <direct include>
39x: command.hh installable-value.hh installables.hh
7x: libexpr.hh
4x: local-store.hh
4x: command-installable-value.hh installable-value.hh installables.hh
3x: binary-cache-store.hh
...
170482 ms: ../src/libutil/serialise.hh (included 201 times, avg 848 ms), included via:
37x: command.hh installable-value.hh installables.hh built-path.hh realisation.hh hash.hh
14x: store-api.hh nar-info.hh hash.hh
11x: <direct include>
7x: primops.hh eval.hh attr-set.hh nixexpr.hh value.hh source-path.hh archive.hh
7x: libexpr.hh value.hh source-path.hh archive.hh
6x: fetchers.hh hash.hh
...
169397 ms: ../src/libcmd/installables.hh (included 53 times, avg 3196 ms), included via:
40x: command.hh installable-value.hh
5x: command-installable-value.hh installable-value.hh
3x: installable-flake.hh installable-value.hh
2x: <direct include>
1x: installable-derived-path.hh
1x: installable-value.hh
...
159740 ms: ../src/libutil/strings.hh (included 221 times, avg 722 ms), included via:
37x: command.hh installable-value.hh installables.hh built-path.hh realisation.hh hash.hh serialise.hh
19x: <direct include>
14x: store-api.hh nar-info.hh hash.hh serialise.hh
11x: serialise.hh
7x: primops.hh eval.hh attr-set.hh nixexpr.hh value.hh source-path.hh archive.hh serialise.hh
7x: libexpr.hh value.hh source-path.hh archive.hh serialise.hh
...
156796 ms: ../src/libcmd/command.hh (included 51 times, avg 3074 ms), included via:
42x: <direct include>
7x: command-installable-value.hh
2x: installable-attr-path.hh
150392 ms: ../src/libutil/types.hh (included 251 times, avg 599 ms), included via:
36x: command.hh installable-value.hh installables.hh path.hh
11x: file-system.hh
10x: globals.hh
6x: fetchers.hh
6x: serialise.hh strings.hh error.hh
5x: archive.hh
...
133101 ms: /nix/store/644b90j1vms44nr18yw3520pzkrg4dd1-boost-1.81.0-dev/include/boost/lexical_cast.hpp (included 226 times, avg 588 ms), included via
:
37x: command.hh installable-value.hh installables.hh built-path.hh realisation.hh hash.hh serialise.hh strings.hh
19x: file-system.hh
11x: store-api.hh nar-info.hh hash.hh serialise.hh strings.hh
7x: primops.hh eval.hh attr-set.hh nixexpr.hh value.hh source-path.hh archive.hh serialise.hh strings.hh
7x: libexpr.hh value.hh source-path.hh archive.hh serialise.hh strings.hh
6x: eval.hh attr-set.hh nixexpr.hh value.hh source-path.hh archive.hh serialise.hh strings.hh
...
132887 ms: /nix/store/h2abv2l8irqj942i5rq9wbrj42kbsh5y-gcc-12.3.0/include/c++/12.3.0/memory (included 262 times, avg 507 ms), included via:
36x: command.hh installable-value.hh installables.hh path.hh types.hh ref.hh
16x: gtest.h
11x: file-system.hh types.hh ref.hh
10x: globals.hh types.hh ref.hh
10x: json.hpp
6x: serialise.hh
...
done in 0.6s.
```
After:
```
lix/lix2 » maintainers/buildtime_report.sh build
Processing all files and saving to '/home/jade/lix/lix2/maintainers/../buildtime.bin'...
done in 0.6s. Run 'ClangBuildAnalyzer --analyze /home/jade/lix/lix2/maintainers/../buildtime.bin' to analyze it.
Analyzing build trace from '/home/jade/lix/lix2/maintainers/../buildtime.bin'...
**** Time summary:
Compilation (551 times):
Parsing (frontend): 1302.1 s
Codegen & opts (backend): 956.3 s
<snip>
**** Expensive headers:
178145 ms: ../src/libutil/error.hh (included 246 times, avg 724 ms), included via:
36x: command.hh installable-value.hh installables.hh derived-path.hh config.hh experimental-features.hh
12x: globals.hh config.hh experimental-features.hh
11x: file-system.hh file-descriptor.hh
6x: <direct include>
6x: serialise.hh strings.hh
6x: fetchers.hh hash.hh serialise.hh strings.hh
...
154043 ms: ../src/libcmd/installable-value.hh (included 52 times, avg 2962 ms), included via:
40x: command.hh
5x: command-installable-value.hh
3x: installable-flake.hh
2x: <direct include>
2x: installable-attr-path.hh
153593 ms: ../src/libstore/store-api.hh (included 152 times, avg 1010 ms), included via:
55x: <direct include>
39x: command.hh installable-value.hh installables.hh
7x: libexpr.hh
4x: local-store.hh
4x: command-installable-value.hh installable-value.hh installables.hh
3x: binary-cache-store.hh
...
149948 ms: ../src/libutil/types.hh (included 251 times, avg 597 ms), included via:
36x: command.hh installable-value.hh installables.hh path.hh
11x: file-system.hh
10x: globals.hh
6x: fetchers.hh
6x: serialise.hh strings.hh error.hh
5x: archive.hh
...
144560 ms: ../src/libcmd/installables.hh (included 53 times, avg 2727 ms), included via:
40x: command.hh installable-value.hh
5x: command-installable-value.hh installable-value.hh
3x: installable-flake.hh installable-value.hh
2x: <direct include>
1x: installable-value.hh
1x: installable-derived-path.hh
...
136585 ms: ../src/libcmd/command.hh (included 51 times, avg 2678 ms), included via:
42x: <direct include>
7x: command-installable-value.hh
2x: installable-attr-path.hh
133394 ms: /nix/store/h2abv2l8irqj942i5rq9wbrj42kbsh5y-gcc-12.3.0/include/c++/12.3.0/memory (included 262 times, avg 509 ms), included via:
36x: command.hh installable-value.hh installables.hh path.hh types.hh ref.hh
16x: gtest.h
11x: file-system.hh types.hh ref.hh
10x: globals.hh types.hh ref.hh
10x: json.hpp
6x: serialise.hh
...
89315 ms: ../src/libstore/derived-path.hh (included 178 times, avg 501 ms), included via:
37x: command.hh installable-value.hh installables.hh
25x: store-api.hh realisation.hh
7x: primops.hh eval.hh attr-set.hh nixexpr.hh value.hh context.hh
6x: eval.hh attr-set.hh nixexpr.hh value.hh context.hh
6x: libexpr.hh value.hh context.hh
6x: shared.hh
...
87347 ms: /nix/store/h2abv2l8irqj942i5rq9wbrj42kbsh5y-gcc-12.3.0/include/c++/12.3.0/ostream (included 273 times, avg 319 ms), included via:
35x: command.hh installable-value.hh installables.hh path.hh types.hh ref.hh memory unique_ptr.h
12x: regex sstream istream
10x: file-system.hh types.hh ref.hh memory unique_ptr.h
10x: gtest.h memory unique_ptr.h
10x: globals.hh types.hh ref.hh memory unique_ptr.h
6x: fetchers.hh types.hh ref.hh memory unique_ptr.h
...
85249 ms: ../src/libutil/config.hh (included 213 times, avg 400 ms), included via:
37x: command.hh installable-value.hh installables.hh derived-path.hh
20x: globals.hh
20x: logging.hh
16x: store-api.hh logging.hh
6x: <direct include>
6x: eval.hh attr-set.hh nixexpr.hh value.hh context.hh derived-path.hh
...
done in 0.5s.
```
Adapated from https://git.lix.systems/lix-project/lix/commit/18aa3e1d570b4ecbb9962376e5fba5757dad8da9
2024-05-30 07:12:34 +03:00
# include <sstream>
2023-12-01 01:50:20 +02:00
# include <regex>
2023-09-03 00:35:16 +03:00
# ifndef _WIN32
# include <dlfcn.h>
# endif
2006-09-05 00:06:23 +03:00
2021-05-10 17:41:10 +03:00
# include <cmath>
2021-05-10 12:47:00 +03:00
2006-09-05 00:06:23 +03:00
namespace nix {
2003-10-31 19:09:31 +02:00
2007-01-29 17:11:32 +02:00
/*************************************************************
* Miscellaneous
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2024-04-05 17:08:18 +03:00
StringMap EvalState : : realiseContext ( const NixStringContext & context , StorePathSet * maybePathsOut , bool isIFD )
2014-05-30 22:43:31 +03:00
{
2021-04-05 16:48:18 +03:00
std : : vector < DerivedPath : : Built > drvs ;
2021-12-20 20:46:55 +02:00
StringMap res ;
2018-02-06 16:38:45 +02:00
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
for ( auto & c : context ) {
2023-01-03 18:44:59 +02:00
auto ensureValid = [ & ] ( const StorePath & p ) {
if ( ! store - > isValidPath ( p ) )
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 < InvalidPathError > ( store - > printStorePath ( p ) ) . debugThrow ( ) ;
2023-01-03 18:44:59 +02:00
} ;
std : : visit ( overloaded {
[ & ] ( const NixStringContextElem : : Built & b ) {
drvs . push_back ( DerivedPath : : Built {
. drvPath = b . drvPath ,
2023-01-12 01:57:18 +02:00
. outputs = OutputsSpec : : Names { b . output } ,
2023-01-03 18:44:59 +02:00
} ) ;
Make the Derived Path family of types inductive for dynamic derivations
We want to be able to write down `foo.drv^bar.drv^baz`:
`foo.drv^bar.drv` is the dynamic derivation (since it is itself a
derivation output, `bar.drv` from `foo.drv`).
To that end, we create `Single{Derivation,BuiltPath}` types, that are
very similar except instead of having multiple outputs (in a set or
map), they have a single one. This is for everything to the left of the
rightmost `^`.
`NixStringContextElem` has an analogous change, and now can reuse
`SingleDerivedPath` at the top level. In fact, if we ever get rid of
`DrvDeep`, `NixStringContextElem` could be replaced with
`SingleDerivedPath` entirely!
Important note: some JSON formats have changed.
We already can *produce* dynamic derivations, but we can't refer to them
directly. Today, we can merely express building or example at the top
imperatively over time by building `foo.drv^bar.drv`, and then with a
second nix invocation doing `<result-from-first>^baz`, but this is not
declarative. The ethos of Nix of being able to write down the full plan
everything you want to do, and then execute than plan with a single
command, and for that we need the new inductive form of these types.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-01-16 00:39:04 +02:00
ensureValid ( b . drvPath - > getBaseStorePath ( ) ) ;
2023-01-03 18:44:59 +02:00
} ,
[ & ] ( const NixStringContextElem : : Opaque & o ) {
auto ctxS = store - > printStorePath ( o . path ) ;
ensureValid ( o . path ) ;
2024-04-05 17:08:18 +03:00
if ( maybePathsOut )
maybePathsOut - > emplace ( o . path ) ;
2023-01-03 18:44:59 +02:00
} ,
[ & ] ( const NixStringContextElem : : DrvDeep & d ) {
/* Treat same as Opaque */
auto ctxS = store - > printStorePath ( d . drvPath ) ;
ensureValid ( d . drvPath ) ;
2024-04-05 17:08:18 +03:00
if ( maybePathsOut )
maybePathsOut - > emplace ( d . drvPath ) ;
2023-01-03 18:44:59 +02:00
} ,
2023-08-16 19:29:23 +03:00
} , c . raw ) ;
2014-05-30 22:04:17 +03:00
}
2018-02-06 16:38:45 +02:00
2021-12-20 20:46:55 +02:00
if ( drvs . empty ( ) ) return { } ;
2018-02-06 16:38:45 +02:00
2024-06-14 19:41:09 +03:00
if ( isIFD & & ! settings . enableImportFromDerivation )
2024-06-29 14:19:04 +03:00
error < EvalBaseError > (
2021-09-22 15:00:56 +03:00
" cannot build '%1%' during evaluation because the option 'allow-import-from-derivation' is disabled " ,
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
drvs . begin ( ) - > to_string ( * store )
) . debugThrow ( ) ;
2018-02-06 16:38:45 +02:00
2021-10-07 14:15:01 +03:00
/* Build/substitute the context. */
2021-04-05 16:48:18 +03:00
std : : vector < DerivedPath > buildReqs ;
for ( auto & d : drvs ) buildReqs . emplace_back ( DerivedPath { d } ) ;
2023-12-24 04:26:12 +02:00
buildStore - > buildPaths ( buildReqs , bmNormal , store ) ;
StorePathSet outputsToCopyAndAllow ;
2020-08-07 22:09:26 +03:00
2023-01-12 01:57:18 +02:00
for ( auto & drv : drvs ) {
2023-12-24 04:26:12 +02:00
auto outputs = resolveDerivedPath ( * buildStore , drv , & * store ) ;
2023-01-12 01:57:18 +02:00
for ( auto & [ outputName , outputPath ] : outputs ) {
2023-12-24 04:26:12 +02:00
outputsToCopyAndAllow . insert ( outputPath ) ;
2024-04-05 17:08:18 +03:00
if ( maybePathsOut )
maybePathsOut - > emplace ( outputPath ) ;
2023-11-30 17:28:33 +02:00
2023-07-13 06:33:43 +03:00
/* Get all the output paths corresponding to the placeholders we had */
if ( experimentalFeatureSettings . isEnabled ( Xp : : CaDerivations ) ) {
res . insert_or_assign (
Make the Derived Path family of types inductive for dynamic derivations
We want to be able to write down `foo.drv^bar.drv^baz`:
`foo.drv^bar.drv` is the dynamic derivation (since it is itself a
derivation output, `bar.drv` from `foo.drv`).
To that end, we create `Single{Derivation,BuiltPath}` types, that are
very similar except instead of having multiple outputs (in a set or
map), they have a single one. This is for everything to the left of the
rightmost `^`.
`NixStringContextElem` has an analogous change, and now can reuse
`SingleDerivedPath` at the top level. In fact, if we ever get rid of
`DrvDeep`, `NixStringContextElem` could be replaced with
`SingleDerivedPath` entirely!
Important note: some JSON formats have changed.
We already can *produce* dynamic derivations, but we can't refer to them
directly. Today, we can merely express building or example at the top
imperatively over time by building `foo.drv^bar.drv`, and then with a
second nix invocation doing `<result-from-first>^baz`, but this is not
declarative. The ethos of Nix of being able to write down the full plan
everything you want to do, and then execute than plan with a single
command, and for that we need the new inductive form of these types.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
2023-01-16 00:39:04 +02:00
DownstreamPlaceholder : : fromSingleDerivedPathBuilt (
SingleDerivedPath : : Built {
. drvPath = drv . drvPath ,
. output = outputName ,
} ) . render ( ) ,
2023-12-24 04:26:12 +02:00
buildStore - > printStorePath ( outputPath )
2023-07-13 06:33:43 +03:00
) ;
}
2020-08-07 22:09:26 +03:00
}
}
2021-12-20 20:46:55 +02:00
2023-12-24 04:26:12 +02:00
if ( store ! = buildStore ) copyClosure ( * buildStore , * store , outputsToCopyAndAllow ) ;
2024-04-05 17:08:18 +03:00
if ( isIFD ) {
for ( auto & outputPath : outputsToCopyAndAllow ) {
/* Add the output of this derivations to the allowed
paths . */
allowPath ( outputPath ) ;
}
2023-12-24 04:26:12 +02:00
}
2021-12-20 20:46:55 +02:00
return res ;
2014-05-30 22:43:31 +03:00
}
2024-02-10 21:56:54 +02:00
static SourcePath realisePath ( EvalState & state , const PosIdx pos , Value & v , std : : optional < SymlinkResolution > resolveSymlinks = SymlinkResolution : : Full )
2021-12-21 09:42:19 +02:00
{
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 ;
2021-12-21 09:42:19 +02:00
2023-01-19 14:23:04 +02:00
auto path = state . coerceToPath ( noPos , v , context , " while realising the context of a path " ) ;
2021-12-21 09:42:19 +02:00
2022-01-21 14:51:05 +02:00
try {
2023-11-30 17:16:17 +02:00
if ( ! context . empty ( ) & & path . accessor = = state . rootFS ) {
2023-10-18 18:34:58 +03:00
auto rewrites = state . realiseContext ( context ) ;
auto realPath = state . toRealPath ( rewriteStrings ( path . path . abs ( ) , rewrites ) , context ) ;
2023-12-06 00:02:59 +02:00
path = { path . accessor , CanonPath ( realPath ) } ;
2023-10-18 18:34:58 +03:00
}
2024-02-10 21:56:54 +02:00
return resolveSymlinks ? path . resolveSymlinks ( * resolveSymlinks ) : path ;
2022-01-21 14:51:05 +02:00
} catch ( Error & e ) {
2022-03-04 20:31:59 +02:00
e . addTrace ( state . positions [ pos ] , " while realising the context of path '%s' " , path ) ;
2022-01-21 14:51:05 +02:00
throw ;
}
2021-12-21 09:42:19 +02:00
}
2023-05-11 02:07:33 +03:00
/**
* Add and attribute to the given attribute map from the output name to
* the output path , or a placeholder .
*
* Where possible the path is used , but for floating CA derivations we
* may not know it . For sake of determinism we always assume we don ' t
* and instead put in a place holder . In either case , however , the
* string context will contain the drv path and output name , so
* downstream derivations will have the proper dependency , and in
* addition , before building , the placeholder will be rewritten to be
* the actual path .
*
* The ' drv ' and ' drvPath ' outputs must correspond .
*/
static void mkOutputString (
EvalState & state ,
BindingsBuilder & attrs ,
const StorePath & drvPath ,
const std : : pair < std : : string , DerivationOutput > & o )
{
2023-05-11 03:47:25 +03:00
state . mkOutputString (
2023-05-11 02:07:33 +03:00
attrs . alloc ( o . first ) ,
2021-03-10 06:22:56 +02:00
SingleDerivedPath : : Built {
. drvPath = makeConstantStorePathRef ( drvPath ) ,
. output = o . first ,
} ,
2023-05-11 02:07:33 +03:00
o . second . path ( * state . store , Derivation : : nameFromPath ( drvPath ) , o . first ) ) ;
}
2014-05-30 22:43:31 +03:00
/* Load and evaluate an expression from path specified by the
argument . */
2022-03-04 20:31:59 +02:00
static void import ( EvalState & state , const PosIdx pos , Value & vPath , Value * vScope , Value & v )
2014-05-30 22:43:31 +03:00
{
2024-02-10 21:56:54 +02:00
auto path = realisePath ( state , pos , vPath , std : : nullopt ) ;
2023-04-06 14:15:50 +03:00
auto path2 = path . path . abs ( ) ;
2006-09-24 20:48:41 +03:00
2019-12-05 20:11:09 +02:00
// FIXME
2020-07-12 05:38:03 +03:00
auto isValidDerivationInStore = [ & ] ( ) - > std : : optional < StorePath > {
2023-04-06 14:15:50 +03:00
if ( ! state . store - > isStorePath ( path2 ) )
2020-07-12 05:38:03 +03:00
return std : : nullopt ;
2023-04-06 14:15:50 +03:00
auto storePath = state . store - > parseStorePath ( path2 ) ;
if ( ! ( state . store - > isValidPath ( storePath ) & & isDerivation ( path2 ) ) )
2020-07-12 05:38:03 +03:00
return std : : nullopt ;
return storePath ;
} ;
2020-08-25 15:06:01 +03:00
2023-04-24 14:20:36 +03:00
if ( auto storePath = isValidDerivationInStore ( ) ) {
Derivation drv = state . store - > readDerivation ( * storePath ) ;
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( 3 + drv . outputs . size ( ) ) ;
2023-04-24 14:20:36 +03:00
attrs . alloc ( state . sDrvPath ) . mkString ( path2 , {
NixStringContextElem : : DrvDeep { . drvPath = * storePath } ,
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
} ) ;
2022-01-04 18:39:16 +02:00
attrs . alloc ( state . sName ) . mkString ( drv . env [ " name " ] ) ;
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( drv . outputs . size ( ) ) ;
2022-01-04 18:39:16 +02:00
for ( const auto & [ i , o ] : enumerate ( drv . outputs ) ) {
2023-01-30 14:05:35 +02:00
mkOutputString ( state , attrs , * storePath , o ) ;
2024-03-14 20:10:31 +02:00
( list [ i ] = state . allocValue ( ) ) - > mkString ( o . first ) ;
import: If the path is a valid .drv file, parse it and generate a derivation attrset.
The generated attrset has drvPath and outPath with the right string context, type 'derivation', outputName with
the right name, all with a list of outputs, and an attribute for each output.
I see three uses for this (though certainly there may be more):
* Using derivations generated by something besides nix-instantiate (e.g. guix)
* Allowing packages provided by channels to be used in nix expressions. If a channel installed a valid deriver
for each package it provides into the store, then those could be imported and used as dependencies or installed
in environment.systemPackages, for example.
* Enable hydra to be consistent in how it treats inputs that are outputs of another build. Right now, if an
input is passed as an argument to the job, it is passed as a derivation, but if it is accessed via NIX_PATH
(i.e. through the <> syntax), then it is a path that can be imported. This is problematic because the build
being depended upon may have been built with non-obvious arguments passed to its jobset file. With this
feature, hydra can just set the name of that input to the path to its drv file in NIX_PATH
2012-07-23 20:41:28 +03:00
}
2024-03-14 20:10:31 +02:00
attrs . alloc ( state . sOutputs ) . mkList ( list ) ;
2022-01-04 18:39:16 +02:00
auto w = state . allocValue ( ) ;
w - > mkAttrs ( attrs ) ;
2020-03-11 17:41:22 +02:00
2021-08-29 20:31:52 +03:00
if ( ! state . vImportedDrvToDerivation ) {
state . vImportedDrvToDerivation = allocRootValue ( state . allocValue ( ) ) ;
2020-03-11 17:41:22 +02:00
state . eval ( state . parseExprFromString (
# include "imported-drv-to-derivation.nix.gen.hh"
2023-10-18 16:32:31 +03:00
, state . rootPath ( CanonPath : : root ) ) , * * state . vImportedDrvToDerivation ) ;
2020-03-11 17:41:22 +02:00
}
2023-01-19 14:23:04 +02:00
state . forceFunction ( * * state . vImportedDrvToDerivation , pos , " while evaluating imported-drv-to-derivation.nix.gen.hh " ) ;
2022-01-04 19:40:39 +02:00
v . mkApp ( * state . vImportedDrvToDerivation , w ) ;
2023-01-19 14:23:04 +02:00
state . forceAttrs ( v , pos , " while calling imported-drv-to-derivation.nix.gen.hh " ) ;
2020-12-22 15:43:20 +02:00
}
else {
2020-08-25 15:06:01 +03:00
if ( ! vScope )
2021-12-21 09:42:19 +02:00
state . evalFile ( path , v ) ;
2014-05-30 22:04:17 +03:00
else {
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * vScope , pos , " while evaluating the first argument passed to builtins.scopedImport " ) ;
2020-08-25 15:06:01 +03:00
2024-03-25 19:20:18 +02:00
Env * env = & state . allocEnv ( vScope - > attrs ( ) - > size ( ) ) ;
2014-05-30 22:04:17 +03:00
env - > up = & state . baseEnv ;
2024-03-25 19:20:18 +02:00
auto staticEnv = std : : make_shared < StaticEnv > ( nullptr , state . staticBaseEnv . get ( ) , vScope - > attrs ( ) - > size ( ) ) ;
2014-05-30 22:04:17 +03:00
unsigned int displ = 0 ;
2024-03-25 19:20:18 +02:00
for ( auto & attr : * vScope - > attrs ( ) ) {
2021-11-30 23:15:02 +02:00
staticEnv - > vars . emplace_back ( attr . name , displ ) ;
2014-05-30 22:04:17 +03:00
env - > values [ displ + + ] = attr . value ;
}
Add primop ‘scopedImport’
‘scopedImport’ works like ‘import’, except that it takes a set of
attributes to be added to the lexical scope of the expression,
essentially extending or overriding the builtin variables. For
instance, the expression
scopedImport { x = 1; } ./foo.nix
where foo.nix contains ‘x’, will evaluate to 1.
This has a few applications:
* It allows getting rid of function argument specifications in package
expressions. For instance, a package expression like:
{ stdenv, fetchurl, libfoo }:
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
can now we written as just
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
and imported in all-packages.nix as:
bar = scopedImport pkgs ./bar.nix;
So whereas we once had dependencies listed in three places
(buildInputs, the function, and the call site), they now only need
to appear in one place.
* It allows overriding builtin functions. For instance, to trace all
calls to ‘map’:
let
overrides = {
map = f: xs: builtins.trace "map called!" (map f xs);
# Ensure that our override gets propagated by calls to
# import/scopedImport.
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
# Also update ‘builtins’.
builtins = builtins // overrides;
};
in scopedImport overrides ./bla.nix
* Similarly, it allows extending the set of builtin functions. For
instance, during Nixpkgs/NixOS evaluation, the Nixpkgs library
functions could be added to the default scope.
There is a downside: calls to scopedImport are not memoized, unlike
import. So importing a file multiple times leads to multiple parsings
/ evaluations. It would be possible to construct the AST only once,
but that would require careful handling of variables/environments.
2014-05-26 14:46:11 +03:00
2020-02-21 19:31:16 +02:00
// No need to call staticEnv.sort(), because
// args[0]->attrs is already sorted.
2021-12-21 09:42:19 +02:00
printTalkative ( " evaluating file '%1%' " , path ) ;
Expr * e = state . parseExprFromFile ( resolveExprPath ( path ) , staticEnv ) ;
Add primop ‘scopedImport’
‘scopedImport’ works like ‘import’, except that it takes a set of
attributes to be added to the lexical scope of the expression,
essentially extending or overriding the builtin variables. For
instance, the expression
scopedImport { x = 1; } ./foo.nix
where foo.nix contains ‘x’, will evaluate to 1.
This has a few applications:
* It allows getting rid of function argument specifications in package
expressions. For instance, a package expression like:
{ stdenv, fetchurl, libfoo }:
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
can now we written as just
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
and imported in all-packages.nix as:
bar = scopedImport pkgs ./bar.nix;
So whereas we once had dependencies listed in three places
(buildInputs, the function, and the call site), they now only need
to appear in one place.
* It allows overriding builtin functions. For instance, to trace all
calls to ‘map’:
let
overrides = {
map = f: xs: builtins.trace "map called!" (map f xs);
# Ensure that our override gets propagated by calls to
# import/scopedImport.
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
# Also update ‘builtins’.
builtins = builtins // overrides;
};
in scopedImport overrides ./bla.nix
* Similarly, it allows extending the set of builtin functions. For
instance, during Nixpkgs/NixOS evaluation, the Nixpkgs library
functions could be added to the default scope.
There is a downside: calls to scopedImport are not memoized, unlike
import. So importing a file multiple times leads to multiple parsings
/ evaluations. It would be possible to construct the AST only once,
but that would require careful handling of variables/environments.
2014-05-26 14:46:11 +03:00
2014-05-30 22:04:17 +03:00
e - > eval ( state , * env , v ) ;
}
Add primop ‘scopedImport’
‘scopedImport’ works like ‘import’, except that it takes a set of
attributes to be added to the lexical scope of the expression,
essentially extending or overriding the builtin variables. For
instance, the expression
scopedImport { x = 1; } ./foo.nix
where foo.nix contains ‘x’, will evaluate to 1.
This has a few applications:
* It allows getting rid of function argument specifications in package
expressions. For instance, a package expression like:
{ stdenv, fetchurl, libfoo }:
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
can now we written as just
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
and imported in all-packages.nix as:
bar = scopedImport pkgs ./bar.nix;
So whereas we once had dependencies listed in three places
(buildInputs, the function, and the call site), they now only need
to appear in one place.
* It allows overriding builtin functions. For instance, to trace all
calls to ‘map’:
let
overrides = {
map = f: xs: builtins.trace "map called!" (map f xs);
# Ensure that our override gets propagated by calls to
# import/scopedImport.
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
# Also update ‘builtins’.
builtins = builtins // overrides;
};
in scopedImport overrides ./bla.nix
* Similarly, it allows extending the set of builtin functions. For
instance, during Nixpkgs/NixOS evaluation, the Nixpkgs library
functions could be added to the default scope.
There is a downside: calls to scopedImport are not memoized, unlike
import. So importing a file multiple times leads to multiple parsings
/ evaluations. It would be possible to construct the AST only once,
but that would require careful handling of variables/environments.
2014-05-26 14:46:11 +03:00
}
}
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_scopedImport ( PrimOp {
2020-08-25 15:06:01 +03:00
. name = " scopedImport " ,
. arity = 2 ,
2022-03-04 20:31:59 +02:00
. fun = [ ] ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2020-08-25 15:06:01 +03:00
{
import ( state , pos , * args [ 1 ] , args [ 0 ] , v ) ;
}
} ) ;
static RegisterPrimOp primop_import ( {
. name = " import " ,
. args = { " path " } ,
2023-01-03 11:11:06 +02:00
// TODO turn "normal path values" into link below
2020-08-25 15:06:01 +03:00
. doc = R " (
2023-10-07 03:53:41 +03:00
Load , parse , and return the Nix expression in the file * path * .
2023-03-28 10:35:49 +03:00
2023-10-07 03:53:41 +03:00
> * * Note * *
>
> Unlike some languages , ` import ` is a regular function in Nix .
2023-03-28 10:35:49 +03:00
2023-10-07 03:27:06 +03:00
The * path * argument must meet the same criteria as an [ interpolated expression ] ( @ docroot @ / language / string - interpolation . md # interpolated - expression ) .
2023-03-28 10:35:49 +03:00
2023-10-07 03:53:41 +03:00
If * path * is a directory , the file ` default . nix ` in that directory is used if it exists .
2020-08-25 15:06:01 +03:00
2023-10-07 03:53:41 +03:00
> * * Example * *
2020-08-25 15:06:01 +03:00
>
2023-10-07 03:53:41 +03:00
> ` ` ` console
> $ echo 123 > default . nix
> ` ` `
>
> Import ` default . nix ` from the current directory .
>
> ` ` ` nix
> import . / .
> ` ` `
>
> 123
2023-03-28 10:35:49 +03:00
2023-10-07 03:53:41 +03:00
Evaluation aborts if the file doesn ’ t exist or contains an invalid Nix expression .
2020-08-25 15:06:01 +03:00
2023-10-07 03:53:41 +03:00
A Nix expression loaded by ` import ` must not contain any * free variables * , that is , identifiers that are not defined in the Nix expression itself and are not built - in .
Therefore , it cannot refer to variables that are in scope at the call site .
> * * Example * *
2020-08-25 15:06:01 +03:00
>
2023-10-07 03:53:41 +03:00
> If you have a calling expression
>
> ` ` ` nix
> rec {
> x = 123 ;
> y = import . / foo . nix ;
> }
> ` ` `
>
> then the following ` foo . nix ` will give an error :
>
> ` ` ` nix
> # foo . nix
> x + 456
> ` ` `
>
> since ` x ` is not in scope in ` foo . nix ` .
> If you want ` x ` to be available in ` foo . nix ` , pass it as a function argument :
>
> ` ` ` nix
> rec {
> x = 123 ;
> y = import . / foo . nix x ;
> }
> ` ` `
>
> and
>
> ` ` ` nix
> # foo . nix
> x : x + 456
> ` ` `
>
> The function argument doesn ’ t have to be called ` x ` in ` foo . nix ` ; any name would work .
2020-08-25 15:06:01 +03:00
) " ,
2022-03-04 20:31:59 +02:00
. fun = [ ] ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2020-08-25 15:06:01 +03:00
{
import ( state , pos , * args [ 0 ] , nullptr , v ) ;
}
} ) ;
Add primop ‘scopedImport’
‘scopedImport’ works like ‘import’, except that it takes a set of
attributes to be added to the lexical scope of the expression,
essentially extending or overriding the builtin variables. For
instance, the expression
scopedImport { x = 1; } ./foo.nix
where foo.nix contains ‘x’, will evaluate to 1.
This has a few applications:
* It allows getting rid of function argument specifications in package
expressions. For instance, a package expression like:
{ stdenv, fetchurl, libfoo }:
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
can now we written as just
stdenv.mkDerivation { ... buildInputs = [ libfoo ]; }
and imported in all-packages.nix as:
bar = scopedImport pkgs ./bar.nix;
So whereas we once had dependencies listed in three places
(buildInputs, the function, and the call site), they now only need
to appear in one place.
* It allows overriding builtin functions. For instance, to trace all
calls to ‘map’:
let
overrides = {
map = f: xs: builtins.trace "map called!" (map f xs);
# Ensure that our override gets propagated by calls to
# import/scopedImport.
import = fn: scopedImport overrides fn;
scopedImport = attrs: fn: scopedImport (overrides // attrs) fn;
# Also update ‘builtins’.
builtins = builtins // overrides;
};
in scopedImport overrides ./bla.nix
* Similarly, it allows extending the set of builtin functions. For
instance, during Nixpkgs/NixOS evaluation, the Nixpkgs library
functions could be added to the default scope.
There is a downside: calls to scopedImport are not memoized, unlike
import. So importing a file multiple times leads to multiple parsings
/ evaluations. It would be possible to construct the AST only once,
but that would require careful handling of variables/environments.
2014-05-26 14:46:11 +03:00
2023-09-03 00:35:16 +03:00
# ifndef _WIN32 // TODO implement via DLL loading on Windows
2014-06-01 17:42:56 +03:00
/* Want reasonable symbol names, so extern C */
/* !!! Should we pass the Pos or the file name too? */
extern " C " typedef void ( * ValueInitializer ) ( EvalState & state , Value & v ) ;
2015-02-23 15:41:53 +02:00
/* Load a ValueInitializer from a DSO and return whatever it initializes */
2022-03-04 20:31:59 +02:00
void prim_importNative ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-06-01 17:42:56 +03:00
{
2022-01-21 14:51:05 +02:00
auto path = realisePath ( state , pos , * args [ 0 ] ) ;
2014-06-01 17:42:56 +03:00
2023-01-19 14:23:04 +02:00
std : : string sym ( state . forceStringNoCtx ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.importNative " ) ) ;
2014-06-01 17:42:56 +03:00
2023-04-06 14:15:50 +03:00
void * handle = dlopen ( path . path . c_str ( ) , RTLD_LAZY | RTLD_LOCAL ) ;
2014-06-01 17:42:56 +03:00
if ( ! handle )
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 < EvalError > ( " could not open '%1%': %2% " , path , dlerror ( ) ) . debugThrow ( ) ;
2014-06-01 17:42:56 +03:00
dlerror ( ) ;
ValueInitializer func = ( ValueInitializer ) dlsym ( handle , sym . c_str ( ) ) ;
if ( ! func ) {
char * message = dlerror ( ) ;
if ( message )
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 < EvalError > ( " could not load symbol '%1%' from '%2%': %3% " , sym , path , message ) . debugThrow ( ) ;
2014-06-01 17:42:56 +03:00
else
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 < EvalError > ( " symbol '%1%' from '%2%' resolved to NULL when a function pointer was expected " , sym , path ) . debugThrow ( ) ;
2014-06-01 17:42:56 +03:00
}
( func ) ( state , v ) ;
/* We don't dlclose because v may be a primop referencing a function in the shared object file */
}
2017-03-30 15:04:21 +03:00
/* Execute a program and parse its output */
2022-03-04 20:31:59 +02:00
void prim_exec ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2017-03-30 15:04:21 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.exec " ) ;
2017-03-31 18:58:41 +03:00
auto elems = args [ 0 ] - > listElems ( ) ;
auto count = args [ 0 ] - > listSize ( ) ;
2022-05-25 13:32:22 +03:00
if ( count = = 0 )
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 < EvalError > ( " at least one argument to 'exec' required " ) . atPos ( pos ) . debugThrow ( ) ;
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 ;
2022-11-29 01:25:36 +02:00
auto program = state . coerceToString ( pos , * elems [ 0 ] , context ,
" while evaluating the first element of the argument passed to builtins.exec " ,
false , false ) . toOwned ( ) ;
2017-03-30 15:04:21 +03:00
Strings commandArgs ;
2022-01-21 17:20:54 +02:00
for ( unsigned int i = 1 ; i < args [ 0 ] - > listSize ( ) ; + + i ) {
2022-11-29 01:25:36 +02:00
commandArgs . push_back (
state . coerceToString ( pos , * elems [ i ] , context ,
" while evaluating an element of the argument passed to builtins.exec " ,
false , false ) . toOwned ( ) ) ;
2022-01-21 17:20:54 +02:00
}
2017-03-30 15:04:21 +03:00
try {
2021-12-20 20:46:55 +02:00
auto _ = state . realiseContext ( context ) ; // FIXME: Handle CA derivations
2017-03-30 15:04:21 +03:00
} catch ( InvalidPathError & e ) {
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 < EvalError > ( " cannot execute '%1%', since path '%2%' is not valid " , program , e . path ) . atPos ( pos ) . debugThrow ( ) ;
2020-06-15 15:06:58 +03:00
}
2017-03-30 15:04:21 +03:00
auto output = runProgram ( program , true , commandArgs ) ;
Expr * parsed ;
try {
2023-04-06 14:15:50 +03:00
parsed = state . parseExprFromString ( std : : move ( output ) , state . rootPath ( CanonPath : : root ) ) ;
2017-03-30 15:04:21 +03:00
} catch ( Error & e ) {
2023-01-19 14:23:04 +02:00
e . addTrace ( state . positions [ pos ] , " while parsing the output from '%1%' " , program ) ;
2017-03-30 15:04:21 +03:00
throw ;
}
try {
state . eval ( parsed , v ) ;
} catch ( Error & e ) {
2023-01-19 14:23:04 +02:00
e . addTrace ( state . positions [ pos ] , " while evaluating the output from '%1%' " , program ) ;
2017-03-30 15:04:21 +03:00
throw ;
}
}
2023-09-03 00:35:16 +03:00
# endif
2013-10-24 03:49:13 +03:00
/* Return a string representing the type of the expression. */
2022-03-04 20:31:59 +02:00
static void prim_typeOf ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2013-10-24 03:49:13 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-02-25 17:00:00 +02:00
std : : string t ;
2020-12-17 15:45:45 +02:00
switch ( args [ 0 ] - > type ( ) ) {
2020-12-12 03:09:10 +02:00
case nInt : t = " int " ; break ;
case nBool : t = " bool " ; break ;
case nString : t = " string " ; break ;
case nPath : t = " path " ; break ;
case nNull : t = " null " ; break ;
case nAttrs : t = " set " ; break ;
case nList : t = " list " ; break ;
case nFunction : t = " lambda " ; break ;
case nExternal :
2024-03-25 19:20:18 +02:00
t = args [ 0 ] - > external ( ) - > typeOf ( ) ;
2014-11-30 20:16:19 +02:00
break ;
2020-12-12 03:09:10 +02:00
case nFloat : t = " float " ; break ;
case nThunk : abort ( ) ;
2013-10-24 03:49:13 +03:00
}
2022-03-05 15:40:24 +02:00
v . mkString ( t ) ;
2013-10-24 03:49:13 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_typeOf ( {
. name = " __typeOf " ,
. args = { " e " } ,
. doc = R " (
Return a string representing the type of the value * e * , namely
` " int " ` , ` " bool " ` , ` " string " ` , ` " path " ` , ` " null " ` , ` " set " ` ,
` " list " ` , ` " lambda " ` or ` " float " ` .
) " ,
. fun = prim_typeOf ,
} ) ;
2013-10-24 03:49:13 +03:00
2007-01-29 17:11:32 +02:00
/* Determine whether the argument is the null value. */
2022-03-04 20:31:59 +02:00
static void prim_isNull ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 17:11:32 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nNull ) ;
2007-01-29 17:11:32 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isNull ( {
. name = " isNull " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to ` null ` , and ` false ` otherwise .
2023-12-20 04:24:38 +02:00
This is equivalent to ` e = = null ` .
2020-08-24 15:31:10 +03:00
) " ,
. fun = prim_isNull ,
} ) ;
2007-01-29 17:11:32 +02:00
2007-05-16 19:17:04 +03:00
/* Determine whether the argument is a function. */
2022-03-04 20:31:59 +02:00
static void prim_isFunction ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-05-16 19:17:04 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nFunction ) ;
2007-05-16 19:17:04 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isFunction ( {
. name = " __isFunction " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a function , and ` false ` otherwise .
) " ,
. fun = prim_isFunction ,
} ) ;
2010-03-31 01:39:48 +03:00
2013-10-24 03:49:13 +03:00
/* Determine whether the argument is an integer. */
2022-03-04 20:31:59 +02:00
static void prim_isInt ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2009-02-05 21:35:40 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nInt ) ;
2009-02-05 21:35:40 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isInt ( {
. name = " __isInt " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to an integer , and ` false ` otherwise .
) " ,
. fun = prim_isInt ,
} ) ;
2016-01-05 01:40:40 +02:00
/* Determine whether the argument is a float. */
2022-03-04 20:31:59 +02:00
static void prim_isFloat ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2016-01-05 01:40:40 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nFloat ) ;
2016-01-05 01:40:40 +02:00
}
2010-03-31 01:39:48 +03:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isFloat ( {
. name = " __isFloat " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a float , and ` false ` otherwise .
) " ,
. fun = prim_isFloat ,
} ) ;
2013-10-24 03:49:13 +03:00
/* Determine whether the argument is a string. */
2022-03-04 20:31:59 +02:00
static void prim_isString ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2009-02-05 21:35:40 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nString ) ;
2009-02-05 21:35:40 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isString ( {
. name = " __isString " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a string , and ` false ` otherwise .
) " ,
. fun = prim_isString ,
} ) ;
2010-03-31 01:39:48 +03:00
2013-10-24 03:49:13 +03:00
/* Determine whether the argument is a Boolean. */
2022-03-04 20:31:59 +02:00
static void prim_isBool ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2009-02-05 21:35:40 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nBool ) ;
2009-02-05 21:35:40 +02:00
}
2007-05-16 19:17:04 +03:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isBool ( {
. name = " __isBool " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a bool , and ` false ` otherwise .
) " ,
. fun = prim_isBool ,
} ) ;
2018-01-29 14:36:59 +02:00
/* Determine whether the argument is a path. */
2022-03-04 20:31:59 +02:00
static void prim_isPath ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-01-29 14:36:59 +02:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nPath ) ;
2018-01-29 14:36:59 +02:00
}
2010-03-31 01:39:48 +03:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isPath ( {
. name = " __isPath " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a path , and ` false ` otherwise .
) " ,
. fun = prim_isPath ,
} ) ;
2023-01-19 14:23:04 +02:00
template < typename Callable >
static inline void withExceptionContext ( Trace trace , Callable & & func )
{
try
{
func ( ) ;
}
catch ( Error & e )
{
e . pushTrace ( trace ) ;
throw ;
}
}
2010-04-21 18:57:11 +03:00
struct CompareValues
{
2021-11-23 00:56:40 +02:00
EvalState & state ;
2023-01-19 14:23:04 +02:00
const PosIdx pos ;
const std : : string_view errorCtx ;
2021-11-23 00:56:40 +02:00
2023-01-19 14:23:04 +02:00
CompareValues ( EvalState & state , const PosIdx pos , const std : : string_view & & errorCtx ) : state ( state ) , pos ( pos ) , errorCtx ( errorCtx ) { } ;
2021-11-23 00:56:40 +02:00
bool operator ( ) ( Value * v1 , Value * v2 ) const
2010-04-21 18:57:11 +03:00
{
2023-01-19 14:23:04 +02:00
return ( * this ) ( v1 , v2 , errorCtx ) ;
}
bool operator ( ) ( Value * v1 , Value * v2 , std : : string_view errorCtx ) const
{
try {
if ( v1 - > type ( ) = = nFloat & & v2 - > type ( ) = = nInt )
2024-03-25 19:20:18 +02:00
return v1 - > fpoint ( ) < v2 - > integer ( ) ;
2023-01-19 14:23:04 +02:00
if ( v1 - > type ( ) = = nInt & & v2 - > type ( ) = = nFloat )
2024-03-25 19:20:18 +02:00
return v1 - > integer ( ) < v2 - > fpoint ( ) ;
2023-01-19 14:23:04 +02:00
if ( v1 - > type ( ) ! = v2 - > type ( ) )
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 < EvalError > ( " cannot compare %s with %s " , showType ( * v1 ) , showType ( * v2 ) ) . debugThrow ( ) ;
2023-04-03 19:15:12 +03:00
// Allow selecting a subset of enum values
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wswitch-enum"
2023-01-19 14:23:04 +02:00
switch ( v1 - > type ( ) ) {
case nInt :
2024-03-25 19:20:18 +02:00
return v1 - > integer ( ) < v2 - > integer ( ) ;
2023-01-19 14:23:04 +02:00
case nFloat :
2024-03-25 19:20:18 +02:00
return v1 - > fpoint ( ) < v2 - > fpoint ( ) ;
2023-01-19 14:23:04 +02:00
case nString :
2023-12-10 10:25:20 +02:00
return strcmp ( v1 - > c_str ( ) , v2 - > c_str ( ) ) < 0 ;
2023-01-19 14:23:04 +02:00
case nPath :
2023-10-19 15:22:05 +03:00
// Note: we don't take the accessor into account
// since it's not obvious how to compare them in a
// reproducible way.
2024-03-25 19:20:18 +02:00
return strcmp ( v1 - > payload . path . path , v2 - > payload . path . path ) < 0 ;
2023-01-19 14:23:04 +02:00
case nList :
// Lexicographic comparison
for ( size_t i = 0 ; ; i + + ) {
if ( i = = v2 - > listSize ( ) ) {
return false ;
} else if ( i = = v1 - > listSize ( ) ) {
return true ;
} else if ( ! state . eqValues ( * v1 - > listElems ( ) [ i ] , * v2 - > listElems ( ) [ i ] , pos , errorCtx ) ) {
return ( * this ) ( v1 - > listElems ( ) [ i ] , v2 - > listElems ( ) [ i ] , " while comparing two list elements " ) ;
}
2022-03-18 01:58:09 +02:00
}
2023-01-19 14:23:04 +02:00
default :
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 < EvalError > ( " cannot compare %s with %s; values of that type are incomparable " , showType ( * v1 ) , showType ( * v2 ) ) . debugThrow ( ) ;
2023-04-03 19:15:12 +03:00
# pragma GCC diagnostic pop
2023-01-19 14:23:04 +02:00
}
} catch ( Error & e ) {
2022-11-29 01:25:36 +02:00
if ( ! errorCtx . empty ( ) )
e . addTrace ( nullptr , errorCtx ) ;
2023-01-19 14:23:04 +02:00
throw ;
2010-04-21 18:57:11 +03:00
}
}
} ;
2013-10-28 19:50:58 +02:00
# if HAVE_BOEHMGC
2022-05-25 16:49:41 +03:00
typedef std : : list < Value * , gc_allocator < Value * > > ValueList ;
2013-10-28 19:50:58 +02:00
# else
2022-02-21 17:25:12 +02:00
typedef std : : list < Value * > ValueList ;
2013-10-28 19:50:58 +02:00
# endif
2024-03-25 19:20:18 +02:00
static Bindings : : const_iterator getAttr (
2021-04-14 00:08:59 +03:00
EvalState & state ,
2022-01-12 19:08:48 +02:00
Symbol attrSym ,
2024-03-25 19:20:18 +02:00
const Bindings * attrSet ,
2023-01-19 14:23:04 +02:00
std : : string_view errorCtx )
2021-04-14 00:08:59 +03:00
{
2024-03-25 19:20:18 +02:00
auto value = attrSet - > find ( attrSym ) ;
2021-04-11 13:14:05 +03:00
if ( value = = attrSet - > end ( ) ) {
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 > ( " attribute '%s' missing " , state . symbols [ attrSym ] ) . withTrace ( noPos , errorCtx ) . debugThrow ( ) ;
2021-04-11 13:14:05 +03:00
}
return value ;
}
2022-03-04 20:31:59 +02:00
static void prim_genericClosure ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 17:11:32 +02:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , noPos , " while evaluating the first argument passed to builtins.genericClosure " ) ;
2007-01-29 17:11:32 +02:00
/* Get the start set. */
2024-03-25 19:20:18 +02:00
auto startSet = getAttr ( state , state . sStartSet , args [ 0 ] - > attrs ( ) , " in the attrset passed as argument to builtins.genericClosure " ) ;
2021-04-11 13:14:05 +03:00
2023-01-19 14:23:04 +02:00
state . forceList ( * startSet - > value , noPos , " while evaluating the 'startSet' attribute passed as argument to builtins.genericClosure " ) ;
2007-01-29 17:11:32 +02:00
2013-10-28 23:51:12 +02:00
ValueList workSet ;
2021-11-24 21:21:34 +02:00
for ( auto elem : startSet - > value - > listItems ( ) )
workSet . push_back ( elem ) ;
2007-01-29 17:11:32 +02:00
2023-01-19 14:23:04 +02:00
if ( startSet - > value - > listSize ( ) = = 0 ) {
v = * startSet - > value ;
return ;
}
2023-01-18 02:19:07 +02:00
2023-01-19 14:23:04 +02:00
/* Get the operator. */
2024-03-25 19:20:18 +02:00
auto op = getAttr ( state , state . sOperator , args [ 0 ] - > attrs ( ) , " in the attrset passed as argument to builtins.genericClosure " ) ;
2023-01-19 14:23:04 +02:00
state . forceFunction ( * op - > value , noPos , " while evaluating the 'operator' attribute passed as argument to builtins.genericClosure " ) ;
2010-04-21 18:57:11 +03:00
2023-01-19 14:23:04 +02:00
/* Construct the closure by applying the operator to elements of
2008-07-11 16:29:04 +03:00
` workSet ' , adding the result to ` workSet ' , continuing until
no new elements are found . */
2013-10-28 23:51:12 +02:00
ValueList res ;
2013-10-28 19:50:58 +02:00
// `doneKeys' doesn't need to be a GC root, because its values are
// reachable from res.
2023-01-19 14:23:04 +02:00
auto cmp = CompareValues ( state , noPos , " while comparing the `key` attributes of two genericClosure elements " ) ;
2022-02-21 17:28:23 +02:00
std : : set < Value * , decltype ( cmp ) > doneKeys ( cmp ) ;
2007-01-29 17:11:32 +02:00
while ( ! workSet . empty ( ) ) {
2013-08-02 19:53:02 +03:00
Value * e = * ( workSet . begin ( ) ) ;
workSet . pop_front ( ) ;
2007-01-29 17:11:32 +02:00
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * e , noPos , " while evaluating one of the elements generated by (or initially passed to) builtins.genericClosure " ) ;
2007-01-29 17:11:32 +02:00
2024-03-25 19:20:18 +02:00
auto key = getAttr ( state , state . sKey , e - > attrs ( ) , " in one of the attrsets generated by (or initially passed to) builtins.genericClosure " ) ;
2023-01-19 14:23:04 +02:00
state . forceValue ( * key - > value , noPos ) ;
2007-01-29 17:11:32 +02:00
2019-10-09 16:51:52 +03:00
if ( ! doneKeys . insert ( key - > value ) . second ) continue ;
2013-10-28 19:50:58 +02:00
res . push_back ( e ) ;
2013-09-02 17:29:15 +03:00
2008-07-11 16:29:04 +03:00
/* Call the `operator' function with `e' as argument. */
2023-01-19 14:23:04 +02:00
Value newElements ;
state . callFunction ( * op - > value , 1 , & e , newElements , noPos ) ;
state . forceList ( newElements , noPos , " while evaluating the return value of the `operator` passed to builtins.genericClosure " ) ;
2010-04-21 18:57:11 +03:00
/* Add the values returned by the operator to the work set. */
2023-01-19 14:23:04 +02:00
for ( auto elem : newElements . listItems ( ) ) {
state . forceValue ( * elem , noPos ) ; // "while evaluating one one of the elements returned by the `operator` passed to builtins.genericClosure");
2021-11-24 21:21:34 +02:00
workSet . push_back ( elem ) ;
2010-04-21 18:57:11 +03:00
}
2007-01-29 17:11:32 +02:00
}
2010-04-21 18:57:11 +03:00
/* Create the result list. */
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( res . size ( ) ) ;
for ( const auto & [ n , i ] : enumerate ( res ) )
list [ n ] = i ;
v . mkList ( list ) ;
2007-01-29 17:11:32 +02:00
}
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_genericClosure ( PrimOp {
2020-08-25 12:25:01 +03:00
. name = " __genericClosure " ,
2022-03-24 04:54:43 +02:00
. args = { " attrset " } ,
2020-08-25 12:25:01 +03:00
. arity = 1 ,
2022-03-24 04:54:43 +02:00
. doc = R " (
2024-02-24 14:34:53 +02:00
` builtins . genericClosure ` iteratively computes the transitive closure over an arbitrary relation defined by a function .
It takes * attrset * with two attributes named ` startSet ` and ` operator ` , and returns a list of attrbute sets :
- ` startSet ` :
The initial list of attribute sets .
- ` operator ` :
A function that takes an attribute set and returns a list of attribute sets .
It defines how each item in the current set is processed and expanded into more items .
Each attribute set in the list ` startSet ` and the list returned by ` operator ` must have an attribute ` key ` , which must support equality comparison .
The value of ` key ` can be one of the following types :
2024-07-03 10:03:41 +03:00
- [ Int ] ( @ docroot @ / language / types . md # type - int )
- [ Float ] ( @ docroot @ / language / types . md # type - float )
- [ Boolean ] ( @ docroot @ / language / types . md # type - boolean )
- [ String ] ( @ docroot @ / language / types . md # type - string )
- [ Path ] ( @ docroot @ / language / types . md # type - path )
- [ List ] ( @ docroot @ / language / types . md # list )
2023-10-19 15:39:41 +03:00
2024-02-24 14:34:53 +02:00
The result is produced by calling the ` operator ` on each ` item ` that has not been called yet , including newly added items , until no new items are added .
Items are compared by their ` key ` attribute .
Common usages are :
- Generating unique collections of items , such as dependency graphs .
- Traversing through structures that may contain cycles or loops .
- Processing data structures with complex internal relationships .
> * * Example * *
>
> ` ` ` nix
> builtins . genericClosure {
> startSet = [ { key = 5 ; } ] ;
> operator = item : [ {
> key = if ( item . key / 2 ) * 2 = = item . key
> then item . key / 2
> else 3 * item . key + 1 ;
> } ] ;
> }
> ` ` `
>
> evaluates to
>
> ` ` ` nix
> [ { key = 5 ; } { key = 16 ; } { key = 8 ; } { key = 4 ; } { key = 2 ; } { key = 1 ; } ]
> ` ` `
2022-03-24 04:54:43 +02:00
) " ,
2020-08-25 12:25:01 +03:00
. fun = prim_genericClosure ,
} ) ;
2007-01-29 17:11:32 +02:00
2022-02-14 23:04:34 +02:00
2022-02-03 22:15:21 +02:00
static RegisterPrimOp primop_break ( {
. name = " break " ,
2022-02-04 23:50:25 +02:00
. args = { " v " } ,
2022-02-03 22:15:21 +02:00
. doc = R " (
2022-05-05 13:29:14 +03:00
In debug mode ( enabled using ` - - debugger ` ) , pause Nix expression evaluation and enter the REPL .
2022-05-05 13:37:43 +03:00
Otherwise , return the argument ` v ` .
2022-02-03 22:15:21 +02:00
) " ,
2022-04-29 19:02:17 +03:00
. fun = [ ] ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2022-02-03 22:15:21 +02:00
{
2024-05-02 00:02:43 +03:00
if ( state . canDebug ( ) ) {
2022-05-05 13:37:43 +03:00
auto error = Error ( ErrorInfo {
. level = lvlInfo ,
2024-02-04 06:35:19 +02:00
. msg = HintFmt ( " breakpoint reached " ) ,
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-05-05 13:37:43 +03:00
} ) ;
2024-05-02 00:02:43 +03:00
state . runDebugRepl ( & error ) ;
2022-02-03 22:15:21 +02:00
}
2022-05-05 13:37:43 +03:00
// Return the value we were passed.
v = * args [ 0 ] ;
2022-02-03 22:15:21 +02:00
}
} ) ;
2020-08-24 14:11:56 +03:00
static RegisterPrimOp primop_abort ( {
. name = " abort " ,
. args = { " s " } ,
. doc = R " (
Abort Nix expression evaluation and print the error message * s * .
) " ,
2022-03-04 20:31:59 +02:00
. fun = [ ] ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2020-08-24 14:11:56 +03:00
{
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-01-19 14:23:04 +02:00
auto s = state . coerceToString ( pos , * args [ 0 ] , context ,
" while evaluating the error message passed to builtins.abort " ) . toOwned ( ) ;
2024-05-22 13:51:46 +03:00
state . error < Abort > ( " evaluation aborted with the following error message: '%1%' " , s ) . setIsFromExpr ( ) . debugThrow ( ) ;
2020-08-24 14:11:56 +03:00
}
} ) ;
2007-01-29 17:11:32 +02:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_throw ( {
. name = " throw " ,
. args = { " s " } ,
. doc = R " (
Throw an error message * s * . This usually aborts Nix expression
evaluation , but in ` nix - env - qa ` and other commands that try to
evaluate a set of derivations to get information about those
derivations , a derivation that throws an error is silently skipped
( which is not the case for ` abort ` ) .
) " ,
2022-03-04 20:31:59 +02:00
. fun = [ ] ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2020-08-24 15:31:10 +03:00
{
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-01-19 14:23:04 +02:00
auto s = state . coerceToString ( pos , * args [ 0 ] , context ,
" while evaluating the error message passed to builtin.throw " ) . toOwned ( ) ;
2024-05-22 13:51:46 +03:00
state . error < ThrownError > ( s ) . setIsFromExpr ( ) . debugThrow ( ) ;
2020-08-24 15:31:10 +03:00
}
} ) ;
2007-04-16 18:03:19 +03:00
2022-03-04 20:31:59 +02:00
static void prim_addErrorContext ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2009-01-27 16:36:44 +02:00
{
try {
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 1 ] , pos ) ;
2010-05-07 15:33:14 +03:00
v = * args [ 1 ] ;
2009-01-27 16:36:44 +02:00
} catch ( Error & e ) {
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 ;
2022-11-29 01:25:36 +02:00
auto message = state . coerceToString ( pos , * args [ 0 ] , context ,
" while evaluating the error message passed to builtins.addErrorContext " ,
false , false ) . toOwned ( ) ;
2024-03-27 17:27:06 +02:00
e . addTrace ( nullptr , HintFmt ( message ) , TracePrint : : Always ) ;
2009-01-27 16:36:44 +02:00
throw ;
}
}
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_addErrorContext ( PrimOp {
2020-08-25 12:25:01 +03:00
. name = " __addErrorContext " ,
. arity = 2 ,
2024-03-24 01:04:30 +02:00
// The normal trace item is redundant
. addTrace = false ,
2020-08-25 12:25:01 +03:00
. fun = prim_addErrorContext ,
} ) ;
2010-05-07 15:33:14 +03:00
2022-03-04 20:31:59 +02:00
static void prim_ceil ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2021-05-10 12:47:00 +03:00
{
2023-01-19 14:23:04 +02:00
auto value = state . forceFloat ( * args [ 0 ] , args [ 0 ] - > determinePos ( pos ) ,
" while evaluating the first argument passed to builtins.ceil " ) ;
2022-01-04 19:40:39 +02:00
v . mkInt ( ceil ( value ) ) ;
2021-05-10 12:47:00 +03:00
}
static RegisterPrimOp primop_ceil ( {
. name = " __ceil " ,
. args = { " double " } ,
. doc = R " (
Converts an IEEE - 754 double - precision floating - point number ( * double * ) to
the next higher integer .
If the datatype is neither an integer nor a " float " , an evaluation error will be
thrown .
) " ,
. fun = prim_ceil ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_floor ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2021-05-10 12:47:00 +03:00
{
2023-01-19 14:23:04 +02:00
auto value = state . forceFloat ( * args [ 0 ] , args [ 0 ] - > determinePos ( pos ) , " while evaluating the first argument passed to builtins.floor " ) ;
2022-01-04 19:40:39 +02:00
v . mkInt ( floor ( value ) ) ;
2021-05-10 12:47:00 +03:00
}
static RegisterPrimOp primop_floor ( {
. name = " __floor " ,
. args = { " double " } ,
. doc = R " (
Converts an IEEE - 754 double - precision floating - point number ( * double * ) to
the next lower integer .
If the datatype is neither an integer nor a " float " , an evaluation error will be
thrown .
) " ,
. fun = prim_floor ,
} ) ;
2013-09-02 17:29:15 +03:00
/* Try evaluating the argument. Success => {success=true; value=something;},
2009-08-25 19:06:46 +03:00
* else = > { success = false ; value = false ; } */
2022-03-04 20:31:59 +02:00
static void prim_tryEval ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2009-08-25 19:06:46 +03:00
{
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( 2 ) ;
2022-06-02 19:26:46 +03:00
2022-06-02 21:29:38 +03:00
/* increment state.trylevel, and decrement it when this function returns. */
2022-07-11 19:21:40 +03:00
MaintainCount trylevel ( state . trylevel ) ;
2022-06-02 21:29:38 +03:00
2024-02-03 04:53:49 +02:00
ReplExitStatus ( * savedDebugRepl ) ( ref < EvalState > es , const ValMap & extraEnv ) = nullptr ;
2024-06-14 19:41:09 +03:00
if ( state . debugRepl & & state . settings . ignoreExceptionsDuringTry )
2022-06-02 19:26:46 +03:00
{
2022-06-02 21:29:38 +03:00
/* to prevent starting the repl from exceptions withing a tryEval, null it. */
savedDebugRepl = state . debugRepl ;
state . debugRepl = nullptr ;
2022-06-02 19:26:46 +03:00
}
2009-08-25 19:06:46 +03:00
try {
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 18:39:16 +02:00
attrs . insert ( state . sValue , args [ 0 ] ) ;
2024-03-21 00:06:23 +02:00
attrs . insert ( state . symbols . create ( " success " ) , & state . vTrue ) ;
2009-09-23 22:19:26 +03:00
} catch ( AssertionError & e ) {
2024-03-21 00:06:23 +02:00
// `value = false;` is unfortunate but removing it is a breaking change.
attrs . insert ( state . sValue , & state . vFalse ) ;
attrs . insert ( state . symbols . create ( " success " ) , & state . vFalse ) ;
2009-08-25 19:06:46 +03:00
}
2022-06-02 19:26:46 +03:00
// restore the debugRepl pointer if we saved it earlier.
if ( savedDebugRepl )
state . debugRepl = savedDebugRepl ;
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
2009-08-25 19:06:46 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_tryEval ( {
. name = " __tryEval " ,
. args = { " e " } ,
. doc = R " (
Try to shallowly evaluate * e * . Return a set containing the
attributes ` success ` ( ` true ` if * e * evaluated successfully ,
` false ` if an error was thrown ) and ` value ` , equalling * e * if
2021-02-03 00:04:36 +02:00
successful and ` false ` otherwise . ` tryEval ` will only prevent
errors created by ` throw ` or ` assert ` from being thrown .
Errors ` tryEval ` will not catch are for example those created
by ` abort ` and type errors generated by builtins . Also note that
this doesn ' t evaluate * e * deeply , so ` let e = { x = throw " " ; } ;
in ( builtins . tryEval e ) . success ` will be ` true ` . Using
` builtins . deepSeq ` one can get the expected result :
` let e = { x = throw " " ; } ; in
2020-08-24 15:31:10 +03:00
( builtins . tryEval ( builtins . deepSeq e e ) ) . success ` will be
` false ` .
) " ,
. fun = prim_tryEval ,
} ) ;
2009-01-27 16:36:44 +02:00
2007-01-29 17:11:32 +02:00
/* Return an environment variable. Use with care. */
2022-03-04 20:31:59 +02:00
static void prim_getEnv ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 17:11:32 +02:00
{
2023-01-19 14:23:04 +02:00
std : : string name ( state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.getEnv " ) ) ;
2024-06-14 19:41:09 +03:00
v . mkString ( state . settings . restrictEval | | state . settings . pureEval ? " " : getEnv ( name ) . value_or ( " " ) ) ;
2007-01-29 17:11:32 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_getEnv ( {
. name = " __getEnv " ,
. args = { " s " } ,
. doc = R " (
` getEnv ` returns the value of the environment variable * s * , or an
empty string if the variable doesn ’ t exist . This function should be
used with care , as it can introduce all sorts of nasty environment
dependencies in your Nix expression .
` getEnv ` is used in Nix Packages to locate the file
` ~ / . nixpkgs / config . nix ` , which contains user - local settings for Nix
Packages . ( That is , it does a ` getEnv " HOME " ` to locate the user ’ s
home directory . )
) " ,
. fun = prim_getEnv ,
} ) ;
2007-10-26 21:25:50 +03:00
2014-09-22 15:53:21 +03:00
/* Evaluate the first argument, then return the second argument. */
2022-03-04 20:31:59 +02:00
static void prim_seq ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-09-22 15:53:21 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2014-09-22 15:53:21 +03:00
v = * args [ 1 ] ;
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_seq ( {
. name = " __seq " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Evaluate * e1 * , then evaluate and return * e2 * . This ensures that a
computation is strict in the value of * e1 * .
) " ,
. fun = prim_seq ,
} ) ;
2014-09-22 15:53:21 +03:00
2014-09-22 17:03:55 +03:00
/* Evaluate the first argument deeply (i.e. recursing into lists and
attrsets ) , then return the second argument . */
2022-03-04 20:31:59 +02:00
static void prim_deepSeq ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-09-22 17:03:55 +03:00
{
state . forceValueDeep ( * args [ 0 ] ) ;
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 1 ] , pos ) ;
2014-09-22 17:03:55 +03:00
v = * args [ 1 ] ;
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_deepSeq ( {
. name = " __deepSeq " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
This is like ` seq e1 e2 ` , except that * e1 * is evaluated * deeply * :
if it ’ s a list or set , its elements or attributes are also
evaluated recursively .
) " ,
. fun = prim_deepSeq ,
} ) ;
2014-09-22 17:03:55 +03:00
2010-03-31 23:09:20 +03:00
/* Evaluate the first expression and print it on standard error. Then
return the second expression . Useful for debugging . */
2022-03-04 20:31:59 +02:00
static void prim_trace ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-08-19 01:12:00 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2020-12-17 15:45:45 +02:00
if ( args [ 0 ] - > type ( ) = = nString )
2023-09-26 04:30:41 +03:00
printError ( " trace: %1% " , args [ 0 ] - > string_view ( ) ) ;
2009-10-22 11:10:12 +03:00
else
2023-12-07 02:03:01 +02:00
printError ( " trace: %1% " , ValuePrinter ( state , * args [ 0 ] ) ) ;
2024-06-14 19:41:09 +03:00
if ( state . settings . builtinsTraceDebugger ) {
2024-05-02 00:02:43 +03:00
state . runDebugRepl ( nullptr ) ;
2024-02-03 03:41:34 +02:00
}
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 1 ] , pos ) ;
2010-03-31 23:09:20 +03:00
v = * args [ 1 ] ;
2007-08-19 01:12:00 +03:00
}
2007-01-29 17:11:32 +02:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_trace ( {
. name = " __trace " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Evaluate * e1 * and print its abstract syntax representation on
standard error . Then return * e2 * . This function is useful for
debugging .
2024-02-21 19:07:39 +02:00
If the
[ ` debugger - on - trace ` ] ( @ docroot @ / command - ref / conf - file . md # conf - debugger - on - trace )
option is set to ` true ` and the ` - - debugger ` flag is given , the
interactive debugger will be started when ` trace ` is called ( like
[ ` break ` ] ( @ docroot @ / language / builtins . md # builtins - break ) ) .
2020-08-24 15:31:10 +03:00
) " ,
. fun = prim_trace ,
} ) ;
2024-04-23 02:21:50 +03:00
static void prim_warn ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
{
2024-04-24 11:56:32 +03:00
// We only accept a string argument for now. The use case for pretty printing a value is covered by `trace`.
// By rejecting non-strings we allow future versions to add more features without breaking existing code.
auto msgStr = state . forceString ( * args [ 0 ] , pos , " while evaluating the first argument; the message passed to builtins.warn " ) ;
2024-04-23 19:07:45 +03:00
{
2024-04-24 11:56:32 +03:00
BaseError msg ( std : : string { msgStr } ) ;
2024-04-23 19:07:45 +03:00
msg . atPos ( state . positions [ pos ] ) ;
auto info = msg . info ( ) ;
info . level = lvlWarn ;
2024-05-22 13:51:46 +03:00
info . isFromExpr = true ;
2024-04-23 19:07:45 +03:00
logWarning ( info ) ;
}
2024-04-23 02:21:50 +03:00
2024-06-14 19:41:09 +03:00
if ( state . settings . builtinsAbortOnWarn ) {
2024-05-07 10:13:58 +03:00
// Not an EvalError or subclass, which would cause the error to be stored in the eval cache.
2024-05-22 13:51:46 +03:00
state . error < EvalBaseError > ( " aborting to reveal stack trace of warning, as abort-on-warn is set " ) . setIsFromExpr ( ) . debugThrow ( ) ;
2024-04-23 02:21:50 +03:00
}
2024-06-14 19:41:09 +03:00
if ( state . settings . builtinsTraceDebugger | | state . settings . builtinsDebuggerOnWarn ) {
2024-05-02 00:02:43 +03:00
state . runDebugRepl ( nullptr ) ;
2024-04-23 02:21:50 +03:00
}
state . forceValue ( * args [ 1 ] , pos ) ;
v = * args [ 1 ] ;
}
static RegisterPrimOp primop_warn ( {
. name = " __warn " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Evaluate * e1 * , which must be a string and print iton standard error as a warning .
Then return * e2 * .
This function is useful for non - critical situations where attention is advisable .
If the
[ ` debugger - on - trace ` ] ( @ docroot @ / command - ref / conf - file . md # conf - debugger - on - trace )
or [ ` debugger - on - warn ` ] ( @ docroot @ / command - ref / conf - file . md # conf - debugger - on - warn )
option is set to ` true ` and the ` - - debugger ` flag is given , the
interactive debugger will be started when ` warn ` is called ( like
[ ` break ` ] ( @ docroot @ / language / builtins . md # builtins - break ) ) .
2024-05-22 13:51:46 +03:00
If the
[ ` abort - on - warn ` ] ( @ docroot @ / command - ref / conf - file . md # conf - abort - on - warn )
option is set , the evaluation will be aborted after the warning is printed .
This is useful to reveal the stack trace of the warning , when the context is non - interactive and a debugger can not be launched .
2024-04-23 02:21:50 +03:00
) " ,
. fun = prim_warn ,
} ) ;
2007-10-26 21:25:50 +03:00
2021-12-13 09:24:24 +02:00
/* Takes two arguments and evaluates to the second one. Used as the
* builtins . traceVerbose implementation when - - trace - verbose is not enabled
*/
2022-07-05 19:56:39 +03:00
static void prim_second ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2021-12-13 09:24:24 +02:00
{
state . forceValue ( * args [ 1 ] , pos ) ;
v = * args [ 1 ] ;
}
2007-01-29 17:11:32 +02:00
/*************************************************************
* Derivations
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2024-03-25 19:20:18 +02:00
static void derivationStrictInternal (
EvalState & state ,
const std : : string & name ,
const Bindings * attrs ,
Value & v ) ;
2007-01-29 17:11:32 +02:00
2004-08-04 13:59:20 +03:00
/* Construct (as a unobservable side effect) a Nix derivation
expression that performs the derivation described by the argument
set . Returns the original set extended with the following
attributes : ` outPath ' containing the primary output path of the
derivation ; ` drvPath ' containing the path of the Nix expression ;
and ` type ' set to ` derivation ' to indicate that this is a
derivation . */
2022-03-04 20:31:59 +02:00
static void prim_derivationStrict ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2003-10-31 19:09:31 +02:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the argument passed to builtins.derivationStrict " ) ;
2003-10-31 19:09:31 +02:00
2024-03-25 19:20:18 +02:00
auto attrs = args [ 0 ] - > attrs ( ) ;
2022-11-29 01:25:36 +02:00
2010-03-31 18:38:03 +03:00
/* Figure out the name first (for stack backtraces). */
2024-03-25 19:20:18 +02:00
auto nameAttr = getAttr ( state , state . sName , attrs , " in the attrset passed as argument to builtins.derivationStrict " ) ;
2021-04-11 14:55:07 +03:00
2022-02-25 17:00:00 +02:00
std : : string drvName ;
2012-11-27 16:01:32 +02:00
try {
2022-11-29 01:25:36 +02:00
drvName = state . forceStringNoCtx ( * nameAttr - > value , pos , " while evaluating the `name` attribute passed to builtins.derivationStrict " ) ;
} catch ( Error & e ) {
e . addTrace ( state . positions [ nameAttr - > pos ] , " while evaluating the derivation attribute 'name' " ) ;
throw ;
}
try {
derivationStrictInternal ( state , drvName , attrs , v ) ;
2006-10-23 19:45:19 +03:00
} catch ( Error & e ) {
2022-11-29 01:25:36 +02:00
Pos pos = state . positions [ nameAttr - > pos ] ;
/*
* Here we make two abuses of the error system
*
* 1. We print the location as a string to avoid a code snippet being
* printed . While the location of the name attribute is a good hint , the
* exact code there is irrelevant .
*
* 2. We mark this trace as a frame trace , meaning that we stop printing
* less important traces from now on . In particular , this prevents the
* display of the automatic " while calling builtins.derivationStrict "
* trace , which is of little use for the public we target here .
*
* Please keep in mind that error reporting is done on a best - effort
* basis in nix . There is no accurate location for a derivation , as it
* often results from the composition of several functions
* ( derivationStrict , derivation , mkDerivation , mkPythonModule , etc . )
*/
2024-02-04 06:35:19 +02:00
e . addTrace ( nullptr , HintFmt (
2022-11-29 01:25:36 +02:00
" while evaluating derivation '%s' \n "
" whose name attribute is located at %s " ,
2024-02-23 03:14:55 +02:00
drvName , pos ) ) ;
2006-10-23 19:45:19 +03:00
throw ;
}
2022-11-29 01:25:36 +02:00
}
2012-11-27 16:01:32 +02:00
2024-06-20 23:20:17 +03:00
/**
* Early validation for the derivation name , for better error message .
* It is checked again when constructing store paths .
*
* @ todo Check that the ` . drv ` suffix also fits .
*/
static void checkDerivationName ( EvalState & state , std : : string_view drvName )
{
try {
checkName ( drvName ) ;
} catch ( BadStorePathName & e ) {
// "Please pass a different name": Users may not be aware that they can
// pass a different one, in functions like `fetchurl` where the name
// is optional.
// Note that Nixpkgs generally won't trigger this, because `mkDerivation`
// sanitizes the name.
state . error < EvalError > ( " invalid derivation name: %s. Please pass a different '%s'. " , Uncolored ( e . message ( ) ) , " name " ) . debugThrow ( ) ;
}
}
2024-03-25 19:20:18 +02:00
static void derivationStrictInternal (
EvalState & state ,
const std : : string & drvName ,
const Bindings * attrs ,
Value & v )
2022-11-29 01:25:36 +02:00
{
2024-06-20 23:20:17 +03:00
checkDerivationName ( state , drvName ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
/* Check whether attributes should be passed as a JSON file. */
2022-11-29 01:25:36 +02:00
using nlohmann : : json ;
2022-11-16 17:49:49 +02:00
std : : optional < json > jsonObject ;
2024-02-01 23:08:06 +02:00
auto pos = v . determinePos ( noPos ) ;
2022-11-29 01:25:36 +02:00
auto attr = attrs - > find ( state . sStructuredAttrs ) ;
if ( attr ! = attrs - > end ( ) & &
2024-02-01 23:08:06 +02:00
state . forceBool ( * attr - > value , pos ,
2022-11-29 01:25:36 +02:00
" while evaluating the `__structuredAttrs` "
" attribute passed to builtins.derivationStrict " ) )
2022-11-16 17:49:49 +02:00
jsonObject = json : : object ( ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
2012-11-27 16:01:32 +02:00
/* Check whether null attributes should be ignored. */
bool ignoreNulls = false ;
2022-11-29 01:25:36 +02:00
attr = attrs - > find ( state . sIgnoreNulls ) ;
if ( attr ! = attrs - > end ( ) )
2024-02-01 23:08:06 +02:00
ignoreNulls = state . forceBool ( * attr - > value , pos , " while evaluating the `__ignoreNulls` attribute " " passed to builtins.derivationStrict " ) ;
2012-11-27 16:01:32 +02:00
2003-10-31 19:09:31 +02:00
/* Build the derivation expression by processing the attributes. */
2005-01-19 13:16:11 +02:00
Derivation drv ;
2020-07-12 06:03:12 +03:00
drv . name = drvName ;
2012-11-27 16:01:32 +02:00
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 ;
2006-10-16 18:55:34 +03:00
2020-07-23 02:59:25 +03:00
bool contentAddressed = false ;
2022-03-30 17:31:01 +03:00
bool isImpure = false ;
2019-02-12 14:43:32 +02:00
std : : optional < std : : string > outputHash ;
2024-04-05 21:10:28 +03:00
std : : optional < HashAlgorithm > outputHashAlgo ;
2022-04-20 01:39:57 +03:00
std : : optional < ContentAddressMethod > ingestionMethod ;
2003-10-31 19:09:31 +02:00
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
StringSet outputs ;
outputs . insert ( " out " ) ;
2022-11-29 01:25:36 +02:00
for ( auto & i : attrs - > lexicographicOrder ( state . symbols ) ) {
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
if ( i - > name = = state . sIgnoreNulls ) continue ;
2024-06-06 17:33:41 +03:00
auto key = state . symbols [ i - > name ] ;
2017-07-30 14:27:57 +03:00
vomit ( " processing attribute '%1%' " , key ) ;
2003-10-31 19:09:31 +02:00
2022-01-21 15:44:00 +02:00
auto handleHashMode = [ & ] ( const std : : string_view s ) {
2024-02-13 22:22:31 +02:00
if ( s = = " recursive " ) {
// back compat, new name is "nar"
2024-05-17 02:08:28 +03:00
ingestionMethod = ContentAddressMethod : : Raw : : NixArchive ;
2024-02-13 22:22:31 +02:00
} else try {
ingestionMethod = ContentAddressMethod : : parse ( s ) ;
} catch ( UsageError & ) {
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 < EvalError > (
" invalid value '%s' for 'outputHashMode' attribute " , s
) . atPos ( v ) . debugThrow ( ) ;
2024-02-13 22:22:31 +02:00
}
2024-05-17 02:08:28 +03:00
if ( ingestionMethod = = ContentAddressMethod : : Raw : : Text )
2024-02-13 22:22:31 +02:00
experimentalFeatureSettings . require ( Xp : : DynamicDerivations ) ;
2024-05-17 02:08:28 +03:00
if ( ingestionMethod = = ContentAddressMethod : : Raw : : Git )
2024-02-13 22:22:31 +02:00
experimentalFeatureSettings . require ( Xp : : GitHashing ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
} ;
auto handleOutputs = [ & ] ( const Strings & ss ) {
outputs . clear ( ) ;
for ( auto & j : ss ) {
if ( outputs . find ( j ) ! = outputs . end ( ) )
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 < EvalError > ( " duplicate derivation output '%1%' " , j )
. atPos ( v )
. debugThrow ( ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
/* !!! Check whether j is a valid attribute
name . */
2024-05-08 18:09:51 +03:00
/* Derivations cannot be named ‘ drvPath’ , because
we already have an attribute ‘ drvPath ’ in
the resulting set ( see state . sDrvPath ) . */
if ( j = = " drvPath " )
state . error < EvalError > ( " invalid derivation output name 'drvPath' " )
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
. atPos ( v )
. debugThrow ( ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
outputs . insert ( j ) ;
}
if ( outputs . empty ( ) )
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 < EvalError > ( " derivation cannot have an empty set of outputs " )
. atPos ( v )
. debugThrow ( ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
} ;
2004-04-02 13:49:37 +03:00
try {
2022-11-29 01:25:36 +02:00
// This try-catch block adds context for most errors.
// Use this empty error context to signify that we defer to it.
const std : : string_view context_below ( " " ) ;
2006-08-28 16:31:06 +03:00
2012-11-27 16:01:32 +02:00
if ( ignoreNulls ) {
2024-02-01 23:08:06 +02:00
state . forceValue ( * i - > value , pos ) ;
2020-12-17 15:45:45 +02:00
if ( i - > value - > type ( ) = = nNull ) continue ;
2012-11-27 16:01:32 +02:00
}
2024-02-01 23:08:06 +02:00
if ( i - > name = = state . sContentAddressed & & state . forceBool ( * i - > value , pos , context_below ) ) {
2023-05-27 18:53:30 +03:00
contentAddressed = true ;
experimentalFeatureSettings . require ( Xp : : CaDerivations ) ;
2020-07-27 20:56:36 +03:00
}
2020-07-23 02:59:25 +03:00
2024-02-01 23:08:06 +02:00
else if ( i - > name = = state . sImpure & & state . forceBool ( * i - > value , pos , context_below ) ) {
2023-05-27 18:53:30 +03:00
isImpure = true ;
experimentalFeatureSettings . require ( Xp : : ImpureDerivations ) ;
2022-03-30 17:31:01 +03:00
}
2006-08-28 16:31:06 +03:00
/* The `args' attribute is special: it supplies the
command - line arguments to the builder . */
2020-08-05 18:05:46 +03:00
else if ( i - > name = = state . sArgs ) {
2024-02-01 23:08:06 +02:00
state . forceList ( * i - > value , pos , context_below ) ;
2021-11-24 21:21:34 +02:00
for ( auto elem : i - > value - > listItems ( ) ) {
2024-02-01 23:08:06 +02:00
auto s = state . coerceToString ( pos , * elem , context ,
2022-11-29 01:25:36 +02:00
" while evaluating an element of the argument list " ,
true ) . toOwned ( ) ;
2006-08-28 16:31:06 +03:00
drv . args . push_back ( s ) ;
}
}
/* All other attributes are passed to the builder through
the environment . */
else {
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
if ( jsonObject ) {
if ( i - > name = = state . sStructuredAttrs ) continue ;
2024-06-06 17:33:41 +03:00
jsonObject - > emplace ( key , printValueAsJSON ( state , true , * i - > value , pos , context ) ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
if ( i - > name = = state . sBuilder )
2024-02-01 23:08:06 +02:00
drv . builder = state . forceString ( * i - > value , context , pos , context_below ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
else if ( i - > name = = state . sSystem )
2024-02-01 23:08:06 +02:00
drv . platform = state . forceStringNoCtx ( * i - > value , pos , context_below ) ;
2017-03-04 15:24:06 +02:00
else if ( i - > name = = state . sOutputHash )
2024-02-01 23:08:06 +02:00
outputHash = state . forceStringNoCtx ( * i - > value , pos , context_below ) ;
2017-03-04 15:24:06 +02:00
else if ( i - > name = = state . sOutputHashAlgo )
2024-04-05 21:10:28 +03:00
outputHashAlgo = parseHashAlgoOpt ( state . forceStringNoCtx ( * i - > value , pos , context_below ) ) ;
2017-03-04 15:24:06 +02:00
else if ( i - > name = = state . sOutputHashMode )
2024-02-01 23:08:06 +02:00
handleHashMode ( state . forceStringNoCtx ( * i - > value , pos , context_below ) ) ;
2017-03-04 15:24:06 +02:00
else if ( i - > name = = state . sOutputs ) {
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
/* Require ‘ outputs’ to be a list of strings. */
2024-02-01 23:08:06 +02:00
state . forceList ( * i - > value , pos , context_below ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
Strings ss ;
2021-11-24 21:21:34 +02:00
for ( auto elem : i - > value - > listItems ( ) )
2024-02-01 23:08:06 +02:00
ss . emplace_back ( state . forceStringNoCtx ( * elem , pos , context_below ) ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
handleOutputs ( ss ) ;
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
}
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
2024-06-10 16:31:21 +03:00
if ( i - > name = = state . sAllowedReferences )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'allowedReferences'; use 'outputChecks.<output>.allowedReferences' instead " , drvName ) ;
if ( i - > name = = state . sAllowedRequisites )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'allowedRequisites'; use 'outputChecks.<output>.allowedRequisites' instead " , drvName ) ;
if ( i - > name = = state . sDisallowedReferences )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'disallowedReferences'; use 'outputChecks.<output>.disallowedReferences' instead " , drvName ) ;
if ( i - > name = = state . sDisallowedRequisites )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'disallowedRequisites'; use 'outputChecks.<output>.disallowedRequisites' instead " , drvName ) ;
if ( i - > name = = state . sMaxSize )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'maxSize'; use 'outputChecks.<output>.maxSize' instead " , drvName ) ;
if ( i - > name = = state . sMaxClosureSize )
warn ( " In a derivation named '%s', 'structuredAttrs' disables the effect of the derivation attribute 'maxClosureSize'; use 'outputChecks.<output>.maxClosureSize' instead " , drvName ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
} else {
2024-02-01 23:08:06 +02:00
auto s = state . coerceToString ( pos , * i - > value , context , context_below , true ) . toOwned ( ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
drv . env . emplace ( key , s ) ;
2022-01-02 01:30:57 +02:00
if ( i - > name = = state . sBuilder ) drv . builder = std : : move ( s ) ;
else if ( i - > name = = state . sSystem ) drv . platform = std : : move ( s ) ;
else if ( i - > name = = state . sOutputHash ) outputHash = std : : move ( s ) ;
2024-04-05 21:10:28 +03:00
else if ( i - > name = = state . sOutputHashAlgo ) outputHashAlgo = parseHashAlgoOpt ( s ) ;
2017-03-04 15:24:06 +02:00
else if ( i - > name = = state . sOutputHashMode ) handleHashMode ( s ) ;
else if ( i - > name = = state . sOutputs )
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
handleOutputs ( tokenizeString < Strings > ( s ) ) ;
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
}
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
2006-08-28 16:31:06 +03:00
}
2004-04-02 13:49:37 +03:00
} catch ( Error & e ) {
2022-11-29 01:25:36 +02:00
e . addTrace ( state . positions [ i - > pos ] ,
2024-02-23 03:14:55 +02:00
HintFmt ( " while evaluating attribute '%1%' of derivation '%2%' " , key , drvName ) ) ;
2006-03-08 16:11:19 +02:00
throw ;
2004-04-02 13:49:37 +03:00
}
2003-10-31 19:09:31 +02:00
}
2012-11-27 16:01:32 +02:00
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
if ( jsonObject ) {
2022-11-16 17:49:49 +02:00
drv . env . emplace ( " __json " , jsonObject - > dump ( ) ) ;
Add support for passing structured data to builders
Previously, all derivation attributes had to be coerced into strings
so that they could be passed via the environment. This is lossy
(e.g. lists get flattened, necessitating configureFlags
vs. configureFlagsArray, of which the latter cannot be specified as an
attribute), doesn't support attribute sets at all, and has size
limitations (necessitating hacks like passAsFile).
This patch adds a new mode for passing attributes to builders, namely
encoded as a JSON file ".attrs.json" in the current directory of the
builder. This mode is activated via the special attribute
__structuredAttrs = true;
(The idea is that one day we can set this in stdenv.mkDerivation.)
For example,
stdenv.mkDerivation {
__structuredAttrs = true;
name = "foo";
buildInputs = [ pkgs.hello pkgs.cowsay ];
doCheck = true;
hardening.format = false;
}
results in a ".attrs.json" file containing (sans the indentation):
{
"buildInputs": [],
"builder": "/nix/store/ygl61ycpr2vjqrx775l1r2mw1g2rb754-bash-4.3-p48/bin/bash",
"configureFlags": [
"--with-foo",
"--with-bar=1 2"
],
"doCheck": true,
"hardening": {
"format": false
},
"name": "foo",
"nativeBuildInputs": [
"/nix/store/10h6li26i7g6z3mdpvra09yyf10mmzdr-hello-2.10",
"/nix/store/4jnvjin0r6wp6cv1hdm5jbkx3vinlcvk-cowsay-3.03"
],
"propagatedBuildInputs": [],
"propagatedNativeBuildInputs": [],
"stdenv": "/nix/store/f3hw3p8armnzy6xhd4h8s7anfjrs15n2-stdenv",
"system": "x86_64-linux"
}
"passAsFile" is ignored in this mode because it's not needed - large
strings are included directly in the JSON representation.
It is up to the builder to do something with the JSON
representation. For example, in bash-based builders, lists/attrsets of
string values could be mapped to bash (associative) arrays.
2017-01-25 17:42:07 +02:00
jsonObject . reset ( ) ;
}
2006-10-16 18:55:34 +03:00
/* Everything in the context of the strings in the derivation
attributes should be added as dependencies of the resulting
derivation . */
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
for ( auto & c : context ) {
2023-01-03 18:44:59 +02:00
std : : visit ( overloaded {
/* Since this allows the builder to gain access to every
path in the dependency graph of the derivation ( including
all outputs ) , all paths in the graph must be added to
this derivation ' s list of inputs to ensure that they are
available when the builder runs . */
[ & ] ( const NixStringContextElem : : DrvDeep & d ) {
/* !!! This doesn't work if readOnlyMode is set. */
StorePathSet refs ;
state . store - > computeFSClosure ( d . drvPath , refs ) ;
for ( auto & j : refs ) {
drv . inputSrcs . insert ( j ) ;
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
if ( j . isDerivation ( ) ) {
drv . inputDrvs . map [ j ] . value = state . store - > readDerivation ( j ) . outputNames ( ) ;
}
2023-01-03 18:44:59 +02:00
}
} ,
[ & ] ( const NixStringContextElem : : Built & b ) {
Allow dynamic derivation deps in `inputDrvs`
We use the same nested map representation we used for goals, again in
order to save space. We might someday want to combine with `inputDrvs`,
by doing `V = bool` instead of `V = std::set<OutputName>`, but we are
not doing that yet for sake of a smaller diff.
The ATerm format for Derivations also needs to be extended, in addition
to the in-memory format. To accomodate this, we added a new basic
versioning scheme, so old versions of Nix will get nice errors. (And
going forward, if the ATerm format changes again the errors will be even
better.)
`parsedStrings`, an internal function used as part of parsing
derivations in A-Term format, used to consume the final `]` but expect
the initial `[` to already be consumed. This made for what looked like
unbalanced brackets at callsites, which was confusing. Now it consumes
both which is hopefully less confusing.
As part of testing, we also created a unit test for the A-Term format for
regular non-experimental derivations too.
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Apply suggestions from code review
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-10-02 01:05:53 +03:00
drv . inputDrvs . ensureSlot ( * b . drvPath ) . value . insert ( b . output ) ;
2023-01-03 18:44:59 +02:00
} ,
[ & ] ( const NixStringContextElem : : Opaque & o ) {
drv . inputSrcs . insert ( o . path ) ;
} ,
2023-08-16 19:29:23 +03:00
} , c . raw ) ;
2006-10-16 18:55:34 +03:00
}
2012-11-27 16:01:32 +02:00
2003-10-31 19:09:31 +02:00
/* Do we have all required attributes? */
2005-01-19 13:16:11 +02:00
if ( drv . builder = = " " )
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 < EvalError > ( " required attribute 'builder' missing " )
. atPos ( v )
. debugThrow ( ) ;
2020-05-09 03:18:28 +03:00
2005-01-19 13:16:11 +02:00
if ( drv . platform = = " " )
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 < EvalError > ( " required attribute 'system' missing " )
. atPos ( v )
. debugThrow ( ) ;
2004-08-24 14:46:05 +03:00
2006-09-21 21:52:05 +03:00
/* Check whether the derivation name is valid. */
2023-04-18 02:02:45 +03:00
if ( isDerivation ( drvName ) & &
2024-05-17 02:08:28 +03:00
! ( ingestionMethod = = ContentAddressMethod : : Raw : : Text & &
2023-04-18 02:02:45 +03:00
outputs . size ( ) = = 1 & &
* ( outputs . begin ( ) ) = = " out " ) )
{
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 < EvalError > (
" derivation names are allowed to end in '%s' only if they produce a single derivation file " ,
drvExtension
) . atPos ( v ) . debugThrow ( ) ;
2023-04-18 02:02:45 +03:00
}
2005-01-20 17:25:01 +02:00
2017-05-15 19:44:58 +03:00
if ( outputHash ) {
2020-07-23 02:59:25 +03:00
/* Handle fixed-output derivations.
Ignore ` __contentAddressed ` because fixed output derivations are
already content addressed . */
2011-07-20 21:26:00 +03:00
if ( outputs . size ( ) ! = 1 | | * ( outputs . begin ( ) ) ! = " out " )
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 < EvalError > (
" multiple outputs are not supported in fixed-output derivations "
) . atPos ( v ) . debugThrow ( ) ;
2012-11-27 16:01:32 +02:00
2024-04-05 21:10:28 +03:00
auto h = newHashAllowEmpty ( * outputHash , outputHashAlgo ) ;
2012-11-27 16:01:32 +02:00
2024-05-17 02:08:28 +03:00
auto method = ingestionMethod . value_or ( ContentAddressMethod : : Raw : : Flat ) ;
2020-10-13 02:51:23 +03:00
2023-01-06 19:52:16 +02:00
DerivationOutput : : CAFixed dof {
2023-07-06 01:53:44 +03:00
. ca = ContentAddress {
. method = std : : move ( method ) ,
. hash = std : : move ( h ) ,
} ,
2023-01-06 19:52:16 +02:00
} ;
2020-10-13 02:51:23 +03:00
drv . env [ " out " ] = state . store - > printStorePath ( dof . path ( * state . store , drvName , " out " ) ) ;
2023-01-06 19:52:16 +02:00
drv . outputs . insert_or_assign ( " out " , std : : move ( dof ) ) ;
2011-07-20 21:26:00 +03:00
}
2022-03-30 17:31:01 +03:00
else if ( contentAddressed | | isImpure ) {
if ( contentAddressed & & isImpure )
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 < EvalError > ( " derivation cannot be both content-addressed and impure " )
. atPos ( v ) . debugThrow ( ) ;
2022-03-30 17:31:01 +03:00
2024-04-05 21:10:28 +03:00
auto ha = outputHashAlgo . value_or ( HashAlgorithm : : SHA256 ) ;
2024-05-17 02:08:28 +03:00
auto method = ingestionMethod . value_or ( ContentAddressMethod : : Raw : : NixArchive ) ;
2022-03-31 17:56:44 +03:00
2020-07-23 02:59:25 +03:00
for ( auto & i : outputs ) {
2020-08-11 04:13:26 +03:00
drv . env [ i ] = hashPlaceholder ( i ) ;
2022-03-30 17:31:01 +03:00
if ( isImpure )
drv . outputs . insert_or_assign ( i ,
DerivationOutput : : Impure {
2023-08-16 19:29:23 +03:00
. method = method ,
2023-11-28 20:02:15 +02:00
. hashAlgo = ha ,
2022-03-30 17:31:01 +03:00
} ) ;
else
drv . outputs . insert_or_assign ( i ,
DerivationOutput : : CAFloating {
2023-08-16 19:29:23 +03:00
. method = method ,
2023-11-28 20:02:15 +02:00
. hashAlgo = ha ,
2022-03-30 17:31:01 +03:00
} ) ;
2020-07-23 02:59:25 +03:00
}
}
2011-07-20 21:26:00 +03:00
else {
2019-12-05 20:11:09 +02:00
/* Compute a hash over the "masked" store derivation, which is
the final one except that in the list of outputs , the
output paths are empty strings , and the corresponding
environment variables have an empty value . This ensures
that changes in the set of output names do get reflected in
the hash . */
2015-07-17 20:24:28 +03:00
for ( auto & i : outputs ) {
2020-08-11 04:13:26 +03:00
drv . env [ i ] = " " ;
2020-01-21 22:14:13 +02:00
drv . outputs . insert_or_assign ( i ,
2022-03-18 04:07:31 +02:00
DerivationOutput : : Deferred { } ) ;
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
}
2003-10-31 19:09:31 +02:00
2020-09-23 17:30:42 +03:00
auto hashModulo = hashDerivationModulo ( * state . store , Derivation ( drv ) , true ) ;
2022-03-16 15:21:09 +02:00
switch ( hashModulo . kind ) {
case DrvHash : : Kind : : Regular :
for ( auto & i : outputs ) {
2022-05-04 08:44:32 +03:00
auto h = get ( hashModulo . hashes , i ) ;
if ( ! h )
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 < AssertionError > (
" derivation produced no hash for output '%s' " ,
i
) . atPos ( v ) . debugThrow ( ) ;
2022-05-04 08:44:32 +03:00
auto outPath = state . store - > makeOutputPath ( i , * h , drvName ) ;
2022-03-16 15:21:09 +02:00
drv . env [ i ] = state . store - > printStorePath ( outPath ) ;
drv . outputs . insert_or_assign (
i ,
2023-08-16 19:29:23 +03:00
DerivationOutput : : InputAddressed {
2022-03-16 15:21:09 +02:00
. path = std : : move ( outPath ) ,
} ) ;
}
break ;
;
case DrvHash : : Kind : : Deferred :
for ( auto & i : outputs ) {
2023-08-16 19:29:23 +03:00
drv . outputs . insert_or_assign ( i , DerivationOutput : : Deferred { } ) ;
2022-03-16 15:21:09 +02:00
}
}
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
}
2011-07-20 21:26:00 +03:00
2003-10-31 19:09:31 +02:00
/* Write the resulting term into the Nix store directory. */
2020-08-23 18:00:25 +03:00
auto drvPath = writeDerivation ( * state . store , drv , state . repair ) ;
2019-12-05 20:11:09 +02:00
auto drvPathS = state . store - > printStorePath ( drvPath ) ;
2003-10-31 19:09:31 +02:00
2019-12-05 20:11:09 +02:00
printMsg ( lvlChatty , " instantiated '%1%' -> '%2%' " , drvName , drvPathS ) ;
2003-10-31 19:09:31 +02:00
2005-01-18 13:15:50 +02:00
/* Optimisation, but required in read-only mode! because in that
* Support multiple outputs. A derivation can declare multiple outputs
by setting the ‘outputs’ attribute. For example:
stdenv.mkDerivation {
name = "aterm-2.5";
src = ...;
outputs = [ "out" "tools" "dev" ];
configureFlags = "--bindir=$(tools)/bin --includedir=$(dev)/include";
}
This derivation creates three outputs, named like this:
/nix/store/gcnqgllbh01p3d448q8q6pzn2nc2gpyl-aterm-2.5
/nix/store/gjf1sgirwfnrlr0bdxyrwzpw2r304j02-aterm-2.5-tools
/nix/store/hp6108bqfgxvza25nnxfs7kj88xi2vdx-aterm-2.5-dev
That is, the symbolic name of the output is suffixed to the store
path (except for the ‘out’ output). Each path is passed to the
builder through the corresponding environment variable, e.g.,
${tools}.
The main reason for multiple outputs is to allow parts of a package
to be distributed and garbage-collected separately. For instance,
most packages depend on Glibc for its libraries, but don't need its
header files. If these are separated into different store paths,
then a package that depends on the Glibc libraries only causes the
libraries and not the headers to be downloaded.
The main problem with multiple outputs is that if one output exists
while the others have been garbage-collected (or never downloaded in
the first place), and we want to rebuild the other outputs, then
this isn't possible because we can't clobber a valid output (it
might be in active use). This currently gives an error message
like:
error: derivation `/nix/store/1s9zw4c8qydpjyrayxamx2z7zzp5pcgh-aterm-2.5.drv' is blocked by its output paths
There are two solutions: 1) Do the build in a chroot. Then we don't
need to overwrite the existing path. 2) Use hash rewriting (see the
ASE-2005 paper). Scary but it should work.
This is not finished yet. There is not yet an easy way to refer to
non-default outputs in Nix expressions. Also, mutually recursive
outputs aren't detected yet and cause the garbage collector to
crash.
2011-07-19 02:31:03 +03:00
case we don ' t actually write store derivations , so we can ' t
2022-03-18 02:36:52 +02:00
read them later . */
{
2022-03-18 04:15:32 +02:00
auto h = hashDerivationModulo ( * state . store , drv , false ) ;
2020-11-19 18:50:06 +02:00
drvHashes . lock ( ) - > insert_or_assign ( drvPath , h ) ;
}
2005-01-18 13:15:50 +02:00
2022-11-29 01:25:36 +02:00
auto result = state . buildBindings ( 1 + drv . outputs . size ( ) ) ;
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
result . alloc ( state . sDrvPath ) . mkString ( drvPathS , {
NixStringContextElem : : DrvDeep { . drvPath = drvPath } ,
} ) ;
2020-08-07 22:09:26 +03:00
for ( auto & i : drv . outputs )
2023-01-30 14:05:35 +02:00
mkOutputString ( state , result , drvPath , i ) ;
2022-11-29 01:25:36 +02:00
v . mkAttrs ( result ) ;
2010-03-31 18:38:03 +03:00
}
2003-11-02 18:31:35 +02:00
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_derivationStrict ( PrimOp {
2020-08-25 12:25:01 +03:00
. name = " derivationStrict " ,
. arity = 1 ,
. fun = prim_derivationStrict ,
} ) ;
2003-11-02 18:31:35 +02:00
2016-08-17 16:12:54 +03:00
/* Return a placeholder string for the specified output that will be
substituted by the corresponding output path at build time . For
2017-07-30 14:27:57 +03:00
example , ' placeholder " out " ' returns the string
2016-08-17 16:12:54 +03:00
/ 1 rz4g4znpzjwh1xymhjpm42vipw92pr73vdgl6xs1hycac8kf2n9 . At build
2022-01-30 10:51:39 +02:00
time , any occurrence of this string in an derivation attribute will
2016-08-17 16:12:54 +03:00
be replaced with the concrete path in the Nix store of the output
2016-11-26 01:37:43 +02:00
‘ out ’ . */
2022-03-04 20:31:59 +02:00
static void prim_placeholder ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2016-08-17 16:12:54 +03:00
{
2023-01-19 14:23:04 +02:00
v . mkString ( hashPlaceholder ( state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.placeholder " ) ) ) ;
2016-08-17 16:12:54 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_placeholder ( {
. name = " placeholder " ,
. args = { " output " } ,
. doc = R " (
Return a placeholder string for the specified * output * that will be
substituted by the corresponding output path at build time . Typical
outputs would be ` " out " ` , ` " bin " ` or ` " dev " ` .
) " ,
. fun = prim_placeholder ,
} ) ;
2016-08-17 16:12:54 +03:00
2007-01-29 17:11:32 +02:00
/*************************************************************
* Paths
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
/* Convert the argument to a path. !!! obsolete? */
2022-03-04 20:31:59 +02:00
static void prim_toPath ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2003-11-02 18:31:35 +02:00
{
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-04-06 14:15:50 +03:00
auto path = state . coerceToPath ( pos , * args [ 0 ] , context , " while evaluating the first argument passed to builtins.toPath " ) ;
v . mkString ( path . path . abs ( ) , context ) ;
2003-11-02 18:31:35 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_toPath ( {
. name = " __toPath " ,
. args = { " s " } ,
. doc = R " (
2020-08-25 12:16:45 +03:00
* * DEPRECATED . * * Use ` / . + " /path " ` to convert a string into an absolute
2020-08-24 15:31:10 +03:00
path . For relative paths , use ` . / . + " /path " ` .
) " ,
. fun = prim_toPath ,
} ) ;
2003-11-02 18:31:35 +02:00
2008-11-20 01:26:19 +02:00
/* Allow a valid store path to be used in an expression. This is
useful in some generated expressions such as in nix - push , which
generates a call to a function with an already existing store path
as argument . You don ' t want to use ` toPath ' here because it copies
the path to the Nix store , which yields a copy like
/ nix / store / newhash - oldhash - oldname . In the past , ` toPath ' had
special case behaviour for store paths , but that created weird
corner cases . */
2022-03-04 20:31:59 +02:00
static void prim_storePath ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-11-20 01:26:19 +02:00
{
2024-06-14 19:41:09 +03:00
if ( state . settings . pureEval )
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 < EvalError > (
" '%s' is not allowed in pure evaluation mode " ,
" builtins.storePath "
) . atPos ( pos ) . debugThrow ( ) ;
2020-08-24 15:31:10 +03:00
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-11-30 17:16:17 +02:00
auto path = state . coerceToPath ( pos , * args [ 0 ] , context , " while evaluating the first argument passed to 'builtins.storePath' " ) . path ;
2016-11-26 01:37:43 +02:00
/* Resolve symlinks in ‘ path’ , unless ‘ path’ itself is a symlink
2012-07-13 01:25:01 +03:00
directly in the store . The latter condition is necessary so
e . g . nix - push does the right thing . */
2023-04-06 14:15:50 +03:00
if ( ! state . store - > isStorePath ( path . abs ( ) ) )
path = CanonPath ( canonPath ( path . abs ( ) , true ) ) ;
if ( ! state . store - > isInStore ( path . abs ( ) ) )
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 < EvalError > ( " path '%1%' is not in the Nix store " , path )
. atPos ( pos ) . debugThrow ( ) ;
2023-04-06 14:15:50 +03:00
auto path2 = state . store - > toStorePath ( path . abs ( ) ) . first ;
2013-12-05 18:51:54 +02:00
if ( ! settings . readOnlyMode )
2020-07-13 17:19:37 +03:00
state . store - > ensurePath ( path2 ) ;
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
context . insert ( NixStringContextElem : : Opaque { . path = path2 } ) ;
2023-04-06 14:15:50 +03:00
v . mkString ( path . abs ( ) , context ) ;
2008-11-20 01:26:19 +02:00
}
2020-08-25 12:16:45 +03:00
static RegisterPrimOp primop_storePath ( {
. name = " __storePath " ,
. args = { " path " } ,
. doc = R " (
This function allows you to define a dependency on an already
existing store path . For example , the derivation attribute ` src
= builtins . storePath / nix / store / f1d18v1y … - source ` causes the
derivation to depend on the specified path , which must exist or
be substitutable . Note that this differs from a plain path
( e . g . ` src = / nix / store / f1d18v1y … - source ` ) in that the latter
causes the path to be * copied * again to the Nix store , resulting
in a new path ( e . g . ` / nix / store / ld01dnzc … - source - source ` ) .
2023-05-17 15:59:47 +03:00
Not available in [ pure evaluation mode ] ( @ docroot @ / command - ref / conf - file . md # conf - pure - eval ) .
2023-06-05 17:25:22 +03:00
See also [ ` builtins . fetchClosure ` ] ( # builtins - fetchClosure ) .
2020-08-25 12:16:45 +03:00
) " ,
. fun = prim_storePath ,
} ) ;
2008-11-20 01:26:19 +02:00
2022-03-04 20:31:59 +02:00
static void prim_pathExists ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2005-08-14 17:00:39 +03:00
{
2023-12-06 00:02:59 +02:00
try {
auto & arg = * args [ 0 ] ;
2023-08-25 18:18:37 +03:00
2023-12-06 00:02:59 +02:00
/* SourcePath doesn't know about trailing slash. */
2024-02-10 21:56:54 +02:00
state . forceValue ( arg , pos ) ;
2023-12-06 00:02:59 +02:00
auto mustBeDir = arg . type ( ) = = nString
& & ( arg . string_view ( ) . ends_with ( " / " )
| | arg . string_view ( ) . ends_with ( " /. " ) ) ;
2019-07-30 12:22:55 +03:00
2024-02-10 21:56:54 +02:00
auto symlinkResolution =
mustBeDir ? SymlinkResolution : : Full : SymlinkResolution : : Ancestors ;
auto path = realisePath ( state , pos , arg , symlinkResolution ) ;
2023-11-30 17:16:17 +02:00
auto st = path . maybeLstat ( ) ;
2023-11-01 16:26:07 +02:00
auto exists = st & & ( ! mustBeDir | | st - > type = = SourceAccessor : : tDirectory ) ;
2023-08-25 18:18:37 +03:00
v . mkBool ( exists ) ;
2015-02-23 15:41:53 +02:00
} catch ( RestrictedPathError & e ) {
2022-01-04 19:40:39 +02:00
v . mkBool ( false ) ;
2015-02-23 15:41:53 +02:00
}
2006-03-10 18:20:42 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_pathExists ( {
. name = " __pathExists " ,
. args = { " path " } ,
. doc = R " (
Return ` true ` if the path * path * exists at evaluation time , and
` false ` otherwise .
) " ,
. fun = prim_pathExists ,
} ) ;
2006-03-10 18:20:42 +02:00
2024-03-24 02:37:58 +02:00
// Ideally, all trailing slashes should have been removed, but it's been like this for
// almost a decade as of writing. Changing it will affect reproducibility.
static std : : string_view legacyBaseNameOf ( std : : string_view path )
{
if ( path . empty ( ) )
return " " ;
auto last = path . size ( ) - 1 ;
if ( path [ last ] = = ' / ' & & last > 0 )
last - = 1 ;
auto pos = path . rfind ( ' / ' , last ) ;
if ( pos = = path . npos )
pos = 0 ;
else
pos + = 1 ;
return path . substr ( pos , last - pos + 1 ) ;
}
2007-01-29 17:11:32 +02:00
/* Return the base name of the given string, i.e., everything
following the last slash . */
2022-03-04 20:31:59 +02:00
static void prim_baseNameOf ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2003-11-02 18:31:35 +02:00
{
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 ;
2024-03-24 02:37:58 +02:00
v . mkString ( legacyBaseNameOf ( * state . coerceToString ( pos , * args [ 0 ] , context ,
2022-11-29 01:25:36 +02:00
" while evaluating the first argument passed to builtins.baseNameOf " ,
false , false ) ) , context ) ;
2003-11-02 18:31:35 +02:00
}
2003-11-05 18:27:40 +02:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_baseNameOf ( {
. name = " baseNameOf " ,
2024-03-24 02:26:12 +02:00
. args = { " x " } ,
2020-08-24 15:31:10 +03:00
. doc = R " (
2024-07-03 10:03:41 +03:00
Return the * base name * of either a [ path value ] ( @ docroot @ / language / types . md # type - path ) * x * or a string * x * , depending on which type is passed , and according to the following rules .
2024-03-24 02:26:12 +02:00
For a path value , the * base name * is considered to be the part of the path after the last directory separator , including any file extensions .
This is the simple case , as path values don ' t have trailing slashes .
When the argument is a string , a more involved logic applies . If the string ends with a ` / ` , only this one final slash is removed .
After this , the * base name * is returned as previously described , assuming ` / ` as the directory separator . ( Note that evaluation must be platform independent . )
This is somewhat similar to the [ GNU ` basename ` ] ( https : //www.gnu.org/software/coreutils/manual/html_node/basename-invocation.html) command, but GNU `basename` will strip any number of trailing slashes.
2020-08-24 15:31:10 +03:00
) " ,
. fun = prim_baseNameOf ,
} ) ;
2003-11-05 18:27:40 +02:00
2007-01-29 17:11:32 +02:00
/* Return the directory of the given path, i.e., everything before the
last slash . Return either a path or a string depending on the type
of the argument . */
2022-03-04 20:31:59 +02:00
static void prim_dirOf ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-24 21:23:32 +03:00
{
2023-04-06 14:15:50 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
if ( args [ 0 ] - > type ( ) = = nPath ) {
auto path = args [ 0 ] - > path ( ) ;
v . mkPath ( path . path . isRoot ( ) ? path : path . parent ( ) ) ;
} else {
2023-04-24 14:20:36 +03:00
NixStringContext context ;
2023-04-06 14:15:50 +03:00
auto path = state . coerceToString ( pos , * args [ 0 ] , context ,
" while evaluating the first argument passed to 'builtins.dirOf' " ,
2022-11-29 01:25:36 +02:00
false , false ) ;
2023-04-06 14:15:50 +03:00
auto dir = dirOf ( * path ) ;
v . mkString ( dir , context ) ;
}
2006-09-24 21:23:32 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_dirOf ( {
. name = " dirOf " ,
. args = { " s " } ,
. doc = R " (
Return the directory part of the string * s * , that is , everything
before the final slash in the string . This is similar to the GNU
` dirname ` command .
) " ,
. fun = prim_dirOf ,
} ) ;
2006-09-24 21:23:32 +03:00
2007-11-21 15:49:59 +02:00
/* Return the contents of a file as a string. */
2022-03-04 20:31:59 +02:00
static void prim_readFile ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-11-21 15:49:59 +02:00
{
2022-01-21 14:51:05 +02:00
auto path = realisePath ( state , pos , * args [ 0 ] ) ;
2023-04-06 14:15:50 +03:00
auto s = path . readFile ( ) ;
2022-02-25 17:00:00 +02:00
if ( s . find ( ( char ) 0 ) ! = std : : string : : npos )
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 < EvalError > (
" the contents of the file '%1%' cannot be represented as a Nix string " ,
path
) . atPos ( pos ) . debugThrow ( ) ;
2022-01-25 00:02:28 +02:00
StorePathSet refs ;
2023-04-06 14:15:50 +03:00
if ( state . store - > isInStore ( path . path . abs ( ) ) ) {
2022-01-25 00:02:28 +02:00
try {
2023-04-06 14:15:50 +03:00
refs = state . store - > queryPathInfo ( state . store - > toStorePath ( path . path . abs ( ) ) . first ) - > references ;
2022-01-25 00:02:28 +02:00
} catch ( Error & ) { // FIXME: should be InvalidPathError
}
2022-11-04 15:19:31 +02:00
// Re-scan references to filter down to just the ones that actually occur in the file.
auto refsSink = PathRefScanSink : : fromPaths ( refs ) ;
refsSink < < s ;
refs = refsSink . getResultPaths ( ) ;
2022-01-25 00:02:28 +02:00
}
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 ;
for ( auto & & p : std : : move ( refs ) ) {
context . insert ( NixStringContextElem : : Opaque {
. path = std : : move ( ( StorePath & & ) p ) ,
} ) ;
}
2016-03-04 12:47:19 +02:00
v . mkString ( s , context ) ;
2007-11-21 15:49:59 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_readFile ( {
. name = " __readFile " ,
. args = { " path " } ,
. doc = R " (
Return the contents of the file * path * as a string .
) " ,
. fun = prim_readFile ,
} ) ;
2007-11-21 15:49:59 +02:00
2014-05-26 18:02:22 +03:00
/* Find a file in the Nix search path. Used to implement <x> paths,
2017-07-30 14:27:57 +03:00
which are desugared to ' findFile __nixPath " x " ' . */
2022-03-04 20:31:59 +02:00
static void prim_findFile ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-05-26 18:02:22 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.findFile " ) ;
2014-05-26 18:02:22 +03:00
2024-04-13 18:35:15 +03:00
LookupPath lookupPath ;
2014-05-26 18:02:22 +03:00
2021-11-24 21:21:34 +02:00
for ( auto v2 : args [ 0 ] - > listItems ( ) ) {
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * v2 , pos , " while evaluating an element of the list passed to builtins.findFile " ) ;
2014-05-26 18:02:22 +03:00
2022-02-25 17:00:00 +02:00
std : : string prefix ;
2024-03-25 19:20:18 +02:00
auto i = v2 - > attrs ( ) - > find ( state . sPrefix ) ;
if ( i ! = v2 - > attrs ( ) - > end ( ) )
2023-01-19 14:23:04 +02:00
prefix = state . forceStringNoCtx ( * i - > value , pos , " while evaluating the `prefix` attribute of an element of the list passed to builtins.findFile " ) ;
2014-05-26 18:02:22 +03:00
2024-03-25 19:20:18 +02:00
i = getAttr ( state , state . sPath , v2 - > attrs ( ) , " in an element of the __nixPath " ) ;
2014-05-26 18:02:22 +03:00
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 ;
2022-11-29 01:25:36 +02:00
auto path = state . coerceToString ( pos , * i - > value , context ,
" while evaluating the `path` attribute of an element of the list passed to builtins.findFile " ,
false , false ) . toOwned ( ) ;
2022-01-27 16:32:14 +02:00
try {
auto rewrites = state . realiseContext ( context ) ;
path = rewriteStrings ( path , rewrites ) ;
} catch ( InvalidPathError & e ) {
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 < EvalError > (
" cannot find '%1%', since path '%2%' is not valid " ,
path ,
e . path
) . atPos ( pos ) . debugThrow ( ) ;
2022-01-27 16:32:14 +02:00
}
2024-04-13 18:35:15 +03:00
lookupPath . elements . emplace_back ( LookupPath : : Elem {
. prefix = LookupPath : : Prefix { . s = prefix } ,
. path = LookupPath : : Path { . s = path } ,
2023-06-23 19:01:10 +03:00
} ) ;
2014-05-30 22:43:31 +03:00
}
2023-01-19 14:23:04 +02:00
auto path = state . forceStringNoCtx ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.findFile " ) ;
2016-04-14 16:32:24 +03:00
2024-04-13 18:35:15 +03:00
v . mkPath ( state . findFile ( lookupPath , path , pos ) ) ;
2014-05-26 18:02:22 +03:00
}
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_findFile ( PrimOp {
2020-08-25 12:25:01 +03:00
. name = " __findFile " ,
2023-10-07 04:49:49 +03:00
. args = { " search-path " , " lookup-path " } ,
2023-05-13 20:52:45 +03:00
. doc = R " (
2023-10-07 04:49:49 +03:00
Find * lookup - path * in * search - path * .
2023-05-13 20:52:45 +03:00
2024-07-03 10:03:41 +03:00
A search path is represented list of [ attribute sets ] ( . / types . md # attribute - set ) with two attributes :
2023-10-07 04:49:49 +03:00
- ` prefix ` is a relative path .
- ` path ` denotes a file system location
The exact syntax depends on the command line interface .
2023-05-13 20:52:45 +03:00
Examples of search path attribute sets :
- ` ` `
{
prefix = " nixos-config " ;
path = " /etc/nixos/configuration.nix " ;
}
` ` `
- ` ` `
{
prefix = " " ;
path = " /nix/var/nix/profiles/per-user/root/channels " ;
}
` ` `
2024-07-03 10:03:41 +03:00
The lookup algorithm checks each entry until a match is found , returning a [ path value ] ( @ docroot @ / language / types . md # type - path ) of the match :
2023-05-13 20:52:45 +03:00
2023-10-07 04:49:49 +03:00
- If * lookup - path * matches ` prefix ` , then the remainder of * lookup - path * ( the " suffix " ) is searched for within the directory denoted by ` path ` .
Note that the ` path ` may need to be downloaded at this point to look inside .
- If the suffix is found inside that directory , then the entry is a match .
The combined absolute path of the directory ( now downloaded if need be ) and the suffix is returned .
2023-05-13 20:52:45 +03:00
2024-07-07 22:57:23 +03:00
[ Lookup path ] ( @ docroot @ / language / constructs / lookup - path . md ) expressions are [ desugared ] ( https : //en.wikipedia.org/wiki/Syntactic_sugar) using this and [`builtins.nixPath`](#builtins-nixPath):
2023-05-13 20:52:45 +03:00
` ` ` nix
< nixpkgs >
` ` `
is equivalent to :
` ` ` nix
builtins . findFile builtins . nixPath " nixpkgs "
` ` `
) " ,
2020-08-25 12:25:01 +03:00
. fun = prim_findFile ,
} ) ;
2019-05-03 15:30:29 +03:00
/* Return the cryptographic hash of a file in base-16. */
2022-03-04 20:31:59 +02:00
static void prim_hashFile ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2019-05-03 15:30:29 +03:00
{
2023-11-28 15:20:27 +02:00
auto algo = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.hashFile " ) ;
std : : optional < HashAlgorithm > ha = parseHashAlgo ( algo ) ;
if ( ! ha )
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 < EvalError > ( " unknown hash algorithm '%1%' " , algo ) . atPos ( pos ) . debugThrow ( ) ;
2019-05-03 15:30:29 +03:00
2022-01-21 14:51:05 +02:00
auto path = realisePath ( state , pos , * args [ 1 ] ) ;
2019-05-03 15:30:29 +03:00
2023-11-28 15:20:27 +02:00
v . mkString ( hashString ( * ha , path . readFile ( ) ) . to_string ( HashFormat : : Base16 , false ) ) ;
2019-05-03 15:30:29 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_hashFile ( {
. name = " __hashFile " ,
. args = { " type " , " p " } ,
. doc = R " (
Return a base - 16 representation of the cryptographic hash of the
file at path * p * . The hash algorithm specified by * type * must be one
of ` " md5 " ` , ` " sha1 " ` , ` " sha256 " ` or ` " sha512 " ` .
) " ,
. fun = prim_hashFile ,
} ) ;
2024-05-03 13:14:01 +03:00
static Value * fileTypeToString ( EvalState & state , SourceAccessor : : Type type )
2023-01-22 21:45:02 +02:00
{
2023-04-06 14:15:50 +03:00
return
2024-05-03 13:14:01 +03:00
type = = SourceAccessor : : Type : : tRegular ? & state . vStringRegular :
type = = SourceAccessor : : Type : : tDirectory ? & state . vStringDirectory :
type = = SourceAccessor : : Type : : tSymlink ? & state . vStringSymlink :
2024-03-20 23:56:42 +02:00
& state . vStringUnknown ;
2023-01-22 21:45:02 +02:00
}
static void prim_readFileType ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
{
2024-02-10 21:56:54 +02:00
auto path = realisePath ( state , pos , * args [ 0 ] , std : : nullopt ) ;
2023-01-22 21:45:02 +02:00
/* Retrieve the directory entry type and stringize it. */
2024-03-20 23:56:42 +02:00
v = * fileTypeToString ( state , path . lstat ( ) . type ) ;
2023-01-22 21:45:02 +02:00
}
static RegisterPrimOp primop_readFileType ( {
. name = " __readFileType " ,
. args = { " p " } ,
. doc = R " (
Determine the directory entry type of a filesystem node , being
one of " directory " , " regular " , " symlink " , or " unknown " .
) " ,
. fun = prim_readFileType ,
} ) ;
2014-10-01 17:17:50 +03:00
/* Read a directory (without . or ..) */
2022-03-04 20:31:59 +02:00
static void prim_readDir ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-10-01 17:17:50 +03:00
{
2022-01-21 14:51:05 +02:00
auto path = realisePath ( state , pos , * args [ 0 ] ) ;
2014-10-01 17:17:50 +03:00
2023-01-22 21:45:02 +02:00
// Retrieve directory entries for all nodes in a directory.
// This is similar to `getFileType` but is optimized to reduce system calls
// on many systems.
2023-04-06 14:15:50 +03:00
auto entries = path . readDirectory ( ) ;
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( entries . size ( ) ) ;
2014-10-01 17:17:50 +03:00
2023-01-22 21:45:02 +02:00
// If we hit unknown directory entry types we may need to fallback to
// using `getFileType` on some systems.
// In order to reduce system calls we make each lookup lazy by using
// `builtins.readFileType` application.
Value * readFileType = nullptr ;
2023-04-06 14:15:50 +03:00
for ( auto & [ name , type ] : entries ) {
if ( ! type ) {
2024-03-20 23:56:42 +02:00
auto & attr = attrs . alloc ( name ) ;
2023-01-22 21:45:02 +02:00
// Some filesystems or operating systems may not be able to return
// detailed node info quickly in this case we produce a thunk to
// query the file type lazily.
auto epath = state . allocValue ( ) ;
2024-02-05 16:13:11 +02:00
epath - > mkPath ( path / name ) ;
2023-01-22 21:45:02 +02:00
if ( ! readFileType )
readFileType = & state . getBuiltin ( " readFileType " ) ;
attr . mkApp ( readFileType , epath ) ;
} else {
// This branch of the conditional is much more likely.
// Here we just stringize the directory entry type.
2024-03-20 23:56:42 +02:00
attrs . insert ( state . symbols . create ( name ) , fileTypeToString ( state , * type ) ) ;
2023-01-22 21:45:02 +02:00
}
2014-10-01 17:17:50 +03:00
}
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
2014-10-01 17:17:50 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_readDir ( {
. name = " __readDir " ,
. args = { " path " } ,
. doc = R " (
Return the contents of the directory * path * as a set mapping
directory entries to the corresponding file type . For instance , if
directory ` A ` contains a regular file ` B ` and another directory
` C ` , then ` builtins . readDir . / A ` will return the set
` ` ` nix
{ B = " regular " ; C = " directory " ; }
` ` `
The possible values for the file type are ` " regular " ` ,
` " directory " ` , ` " symlink " ` and ` " unknown " ` .
) " ,
. fun = prim_readDir ,
} ) ;
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 06:22:56 +02:00
/* Extend single element string context with another output. */
static void prim_outputOf ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
{
SingleDerivedPath drvPath = state . coerceToSingleDerivedPath ( pos , * args [ 0 ] , " while evaluating the first argument to builtins.outputOf " ) ;
2023-08-25 16:53:12 +03:00
OutputNameView outputName = state . forceStringNoCtx ( * args [ 1 ] , pos , " while evaluating the second argument to builtins.outputOf " ) ;
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 06:22:56 +02:00
state . mkSingleDerivedPathString (
SingleDerivedPath : : Built {
. drvPath = make_ref < SingleDerivedPath > ( drvPath ) ,
. output = std : : string { outputName } ,
} ,
v ) ;
}
static RegisterPrimOp primop_outputOf ( {
. name = " __outputOf " ,
. args = { " derivation-reference " , " output-name " } ,
. doc = R " (
Return the output path of a derivation , literally or using a placeholder if needed .
If the derivation has a statically - known output path ( i . e . the derivation output is input - addressed , or fixed content - addresed ) , the output path will just be returned .
But if the derivation is content - addressed or if the derivation is itself not - statically produced ( i . e . is the output of another derivation ) , a placeholder will be returned instead .
* ` derivation reference ` * must be a string that may contain a regular store path to a derivation , or may be a placeholder reference . If the derivation is produced by a derivation , you must explicitly select ` drv . outPath ` .
This primop can be chained arbitrarily deeply .
For instance ,
2024-04-06 00:19:32 +03:00
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 06:22:56 +02:00
` ` ` nix
builtins . outputOf
2024-01-25 16:30:51 +02:00
( builtins . outputOf myDrv " out " )
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 06:22:56 +02:00
" out "
` ` `
2024-04-06 00:19:32 +03:00
Create `outputOf` primop.
In the Nix language, given a drv path, we should be able to construct
another string referencing to one of its output. We can do this today
with `(import drvPath).output`, but this only works for derivations we
already have.
With dynamic derivations, however, that doesn't work well because the
`drvPath` isn't yet built: importing it like would need to trigger IFD,
when the whole point of this feature is to do "dynamic build graph"
without IFD!
Instead, what we want to do is create a placeholder value with the right
string context to refer to the output of the as-yet unbuilt derivation.
A new primop in the language, analogous to `builtins.placeholder` can be
used to create one. This will achieve all the right properties. The
placeholder machinery also will match out the `outPath` attribute for CA
derivations works.
In 60b7121d2c6d4322b7c2e8e7acfec7b701b2d3a1 we added that type of
placeholder, and the derived path and string holder changes necessary to
support it. Then in the previous commit we cleaned up the code
(inspiration finally hit me!) to deduplicate the code and expose exactly
what we need. Now, we can wire up the primop trivally!
Part of RFC 92: dynamic derivations (tracking issue #6316)
Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>
2021-03-10 06:22:56 +02:00
will return a placeholder for the output of the output of ` myDrv ` .
This primop corresponds to the ` ^ ` sigil for derivable paths , e . g . as part of installable syntax on the command line .
) " ,
. fun = prim_outputOf ,
. experimentalFeature = Xp : : DynamicDerivations ,
} ) ;
2014-05-26 18:02:22 +03:00
2007-01-29 17:11:32 +02:00
/*************************************************************
* Creating files
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2006-09-01 15:07:31 +03:00
/* Convert the argument (which can be any Nix expression) to an XML
representation returned in a string . Not all Nix expressions can
be sensibly or completely represented ( e . g . , functions ) . */
2022-03-04 20:31:59 +02:00
static void prim_toXML ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-08-24 17:34:29 +03:00
{
2006-09-05 00:06:23 +03:00
std : : ostringstream out ;
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 ;
2021-11-14 03:29:31 +02:00
printValueAsXML ( state , true , false , * args [ 0 ] , out , context , pos ) ;
2022-01-04 19:24:42 +02:00
v . mkString ( out . str ( ) , context ) ;
2006-08-24 17:34:29 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_toXML ( {
. name = " __toXML " ,
. args = { " e " } ,
. doc = R " (
Return a string containing an XML representation of * e * . The main
application for ` toXML ` is to communicate information with the
builder in a more structured format than plain environment
variables .
Here is an example where this is the case :
` ` ` nix
{ stdenv , fetchurl , libxslt , jira , uberwiki } :
stdenv . mkDerivation ( rec {
name = " web-server " ;
buildInputs = [ libxslt ] ;
builder = builtins . toFile " builder.sh " "
source $ stdenv / setup
mkdir $ out
echo " $servlets " | xsltproc $ { stylesheet } - > $ out / server - conf . xml ①
" ;
stylesheet = builtins . toFile " stylesheet.xsl " ②
" <?xml version='1.0' encoding='UTF-8'?>
< xsl : stylesheet xmlns : xsl = ' http : //www.w3.org/1999/XSL/Transform' version='1.0'>
< xsl : template match = ' / ' >
< Configure >
< xsl : for - each select = ' / expr / list / attrs ' >
< Call name = ' addWebApplication ' >
< Arg > < xsl : value - of select = \ " attr[@name = 'path']/string/@value \" /></Arg>
< Arg > < xsl : value - of select = \ " attr[@name = 'war']/path/@value \" /></Arg>
< / Call >
< / xsl : for - each >
< / Configure >
< / xsl : template >
< / xsl : stylesheet >
" ;
servlets = builtins . toXML [ ③
{ path = " /bugtracker " ; war = jira + " /lib/atlassian-jira.war " ; }
{ path = " /wiki " ; war = uberwiki + " /uberwiki.war " ; }
] ;
} )
` ` `
The builder is supposed to generate the configuration file for a
[ Jetty servlet container ] ( http : //jetty.mortbay.org/). A servlet
container contains a number of servlets ( ` * . war ` files ) each
exported under a specific URI prefix . So the servlet configuration
is a list of sets containing the ` path ` and ` war ` of the servlet
( ① ) . This kind of information is difficult to communicate with the
normal method of passing information through an environment
variable , which just concatenates everything together into a
string ( which might just work in this case , but wouldn ’ t work if
fields are optional or contain lists themselves ) . Instead the Nix
expression is converted to an XML representation with ` toXML ` ,
which is unambiguous and can easily be processed with the
appropriate tools . For instance , in the example an XSLT stylesheet
( at point ② ) is applied to it ( at point ① ) to generate the XML
configuration file for the Jetty server . The XML representation
produced at point ③ by ` toXML ` is as follows :
` ` ` xml
< ? xml version = ' 1.0 ' encoding = ' utf - 8 ' ? >
< expr >
< list >
< attrs >
< attr name = " path " >
< string value = " /bugtracker " / >
< / attr >
< attr name = " war " >
< path value = " /nix/store/d1jh9pasa7k2...-jira/lib/atlassian-jira.war " / >
< / attr >
< / attrs >
< attrs >
< attr name = " path " >
< string value = " /wiki " / >
< / attr >
< attr name = " war " >
< path value = " /nix/store/y6423b1yi4sx...-uberwiki/uberwiki.war " / >
< / attr >
< / attrs >
< / list >
< / expr >
` ` `
Note that we used the ` toFile ` built - in to write the builder and
the stylesheet “ inline ” in the Nix expression . The path of the
stylesheet is spliced into the builder using the syntax ` xsltproc
$ { stylesheet } ` .
) " ,
. fun = prim_toXML ,
} ) ;
2006-08-24 17:34:29 +03:00
2013-11-19 01:03:11 +02:00
/* Convert the argument (which can be any Nix expression) to a JSON
string . Not all Nix expressions can be sensibly or completely
represented ( e . g . , functions ) . */
2022-03-04 20:31:59 +02:00
static void prim_toJSON ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2013-11-19 01:03:11 +02:00
{
std : : ostringstream out ;
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 ;
2021-10-26 00:13:35 +03:00
printValueAsJSON ( state , true , * args [ 0 ] , pos , out , context ) ;
2022-01-04 19:24:42 +02:00
v . mkString ( out . str ( ) , context ) ;
2013-11-19 01:03:11 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_toJSON ( {
. name = " __toJSON " ,
. args = { " e " } ,
. doc = R " (
Return a string containing a JSON representation of * e * . Strings ,
integers , floats , booleans , nulls and lists are mapped to their JSON
equivalents . Sets ( except derivations ) are represented as objects .
Derivations are translated to a JSON string containing the
derivation ’ s output path . Paths are copied to the store and
represented as a JSON string of the resulting store path .
) " ,
. fun = prim_toJSON ,
} ) ;
2013-11-19 01:03:11 +02:00
2014-07-04 14:34:15 +03:00
/* Parse a JSON string to a value. */
2022-03-04 20:31:59 +02:00
static void prim_fromJSON ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-07-04 14:34:15 +03:00
{
2023-01-19 14:23:04 +02:00
auto s = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.fromJSON " ) ;
2020-12-11 17:31:14 +02:00
try {
parseJSON ( state , s , v ) ;
} catch ( JSONParseError & e ) {
2022-03-04 20:31:59 +02:00
e . addTrace ( state . positions [ pos ] , " while decoding a JSON string " ) ;
2021-09-27 15:35:55 +03:00
throw ;
2020-12-11 17:31:14 +02:00
}
2014-07-04 14:34:15 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_fromJSON ( {
. name = " __fromJSON " ,
. args = { " e " } ,
. doc = R " (
Convert a JSON string to a Nix value . For example ,
` ` ` nix
builtins . fromJSON ' ' { " x " : [ 1 , 2 , 3 ] , " y " : null } ' '
` ` `
returns the value ` { x = [ 1 2 3 ] ; y = null ; } ` .
) " ,
. fun = prim_fromJSON ,
} ) ;
2014-07-04 14:34:15 +03:00
2006-09-01 15:07:31 +03:00
/* Store a string in the Nix store as a source file that can be used
as an input by derivations . */
2022-03-04 20:31:59 +02:00
static void prim_toFile ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-01 15:07:31 +03:00
{
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-01-19 14:23:04 +02:00
std : : string name ( state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.toFile " ) ) ;
std : : string contents ( state . forceString ( * args [ 1 ] , context , pos , " while evaluating the second argument passed to builtins.toFile " ) ) ;
2006-10-03 17:55:54 +03:00
2019-12-05 20:11:09 +02:00
StorePathSet refs ;
2006-10-03 17:55:54 +03:00
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
for ( auto c : context ) {
2023-08-16 19:29:23 +03:00
if ( auto p = std : : get_if < NixStringContextElem : : Opaque > ( & c . raw ) )
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
refs . insert ( p - > path ) ;
else
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 < EvalError > (
" files created by %1% may not reference derivations, but %2% references %3% " ,
" builtins.toFile " ,
name ,
c . to_string ( )
) . atPos ( pos ) . debugThrow ( ) ;
2006-10-03 17:55:54 +03:00
}
2013-09-02 17:29:15 +03:00
2022-04-21 23:41:37 +03:00
auto storePath = settings . readOnlyMode
2023-11-09 04:11:48 +02:00
? state . store - > makeFixedOutputPathFromCA ( name , TextInfo {
. hash = hashString ( HashAlgorithm : : SHA256 , contents ) ,
. references = std : : move ( refs ) ,
} )
: ( {
StringSource s { contents } ;
2024-05-17 02:08:28 +03:00
state . store - > addToStoreFromDump ( s , name , FileSerialisationMethod : : Flat , ContentAddressMethod : : Raw : : Text , HashAlgorithm : : SHA256 , refs , state . repair ) ;
2023-11-09 04:11:48 +02:00
} ) ;
2006-10-03 17:55:54 +03:00
2006-10-16 18:55:34 +03:00
/* Note: we don't need to add `context' to the context of the
result , since ` storePath ' itself has references to the paths
used in args [ 1 ] . */
2010-03-31 18:38:03 +03:00
2022-04-21 23:41:37 +03:00
/* Add the output of this to the allowed paths. */
state . allowAndSetStorePathString ( storePath , v ) ;
2006-09-01 15:07:31 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_toFile ( {
. name = " __toFile " ,
. args = { " name " , " s " } ,
. doc = R " (
Store the string * s * in a file in the Nix store and return its
path . The file has suffix * name * . This file can be used as an
input to derivations . One application is to write builders
“ inline ” . For instance , the following Nix expression combines the
2023-01-03 11:11:06 +02:00
Nix expression for GNU Hello and its build script into one file :
2020-08-24 15:31:10 +03:00
` ` ` nix
{ stdenv , fetchurl , perl } :
stdenv . mkDerivation {
name = " hello-2.1.1 " ;
builder = builtins . toFile " builder.sh " "
source $ stdenv / setup
PATH = $ perl / bin : $ PATH
tar xvfz $ src
cd hello - *
. / configure - - prefix = $ out
make
make install
" ;
src = fetchurl {
url = " http://ftp.nluug.nl/pub/gnu/hello/hello-2.1.1.tar.gz " ;
sha256 = " 1md7jsfd8pa45z73bz1kszpp01yw6x5ljkjk2hx7wl800any6465 " ;
} ;
inherit perl ;
}
` ` `
It is even possible for one file to refer to another , e . g . ,
` ` ` nix
builder = let
configFile = builtins . toFile " foo.conf " "
# This is some dummy configuration file.
. . .
" ;
in builtins . toFile " builder.sh " "
source $ stdenv / setup
. . .
cp $ { configFile } $ out / etc / foo . conf
" ;
2020-09-16 15:18:46 +03:00
` ` `
2020-08-24 15:31:10 +03:00
2022-11-09 01:31:48 +02:00
Note that ` $ { configFile } ` is a
2024-07-03 10:03:41 +03:00
[ string interpolation ] ( @ docroot @ / language / types . md # type - string ) , so the result of the
2020-08-24 15:31:10 +03:00
expression ` configFile `
( i . e . , a path like ` / nix / store / m7p7jfny445k . . . - foo . conf ` ) will be
spliced into the resulting string .
It is however * not * allowed to have files mutually referring to each
other , like so :
` ` ` nix
let
foo = builtins . toFile " foo " " ...${bar}... " ;
bar = builtins . toFile " bar " " ...${foo}... " ;
in foo
` ` `
This is not allowed because it would cause a cyclic dependency in
the computation of the cryptographic hashes for ` foo ` and ` bar ` .
It is also not possible to reference the result of a derivation . If
you are using Nixpkgs , the ` writeTextFile ` function is able to do
that .
) " ,
. fun = prim_toFile ,
} ) ;
2006-09-01 15:07:31 +03:00
2023-11-30 17:16:17 +02:00
bool EvalState : : callPathFilter (
Value * filterFun ,
const SourcePath & path ,
std : : string_view pathArg ,
PosIdx pos )
{
auto st = path . lstat ( ) ;
/* Call the filter function. The first argument is the path, the
second is a string indicating the type of the file . */
Value arg1 ;
arg1 . mkString ( pathArg ) ;
// assert that type is not "unknown"
2024-03-20 23:56:42 +02:00
Value * args [ ] { & arg1 , fileTypeToString ( * this , st . type ) } ;
2023-11-30 17:16:17 +02:00
Value res ;
callFunction ( * filterFun , 2 , args , res , pos ) ;
return forceBool ( res , pos , " while evaluating the return value of the path filter function " ) ;
}
2021-10-07 14:43:17 +03:00
static void addPath (
EvalState & state ,
2022-03-04 20:31:59 +02:00
const PosIdx pos ,
2023-04-06 14:15:50 +03:00
std : : string_view name ,
2023-11-30 17:16:17 +02:00
SourcePath path ,
2021-10-07 14:43:17 +03:00
Value * filterFun ,
2024-04-13 19:10:12 +03:00
ContentAddressMethod method ,
2021-10-07 14:43:17 +03:00
const std : : optional < Hash > expectedHash ,
Value & v ,
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
const NixStringContext & context )
2004-02-04 18:03:29 +02:00
{
2021-10-07 14:43:17 +03:00
try {
2021-11-09 11:24:49 +02:00
StorePathSet refs ;
2021-10-23 21:31:46 +03:00
2023-11-30 17:16:17 +02:00
if ( path . accessor = = state . rootFS & & state . store - > isInStore ( path . path . abs ( ) ) ) {
// FIXME: handle CA derivation outputs (where path needs to
// be rewritten to the actual output).
auto rewrites = state . realiseContext ( context ) ;
path = { state . rootFS , CanonPath ( state . toRealPath ( rewriteStrings ( path . path . abs ( ) , rewrites ) , context ) ) } ;
2022-01-25 00:02:28 +02:00
try {
2023-11-30 17:16:17 +02:00
auto [ storePath , subPath ] = state . store - > toStorePath ( path . path . abs ( ) ) ;
2022-01-25 00:02:28 +02:00
// FIXME: we should scanForReferences on the path before adding it
refs = state . store - > queryPathInfo ( storePath ) - > references ;
2023-11-30 17:16:17 +02:00
path = { state . rootFS , CanonPath ( state . store - > toRealPath ( storePath ) + subPath ) } ;
2022-01-25 00:02:28 +02:00
} catch ( Error & ) { // FIXME: should be InvalidPathError
}
2021-10-07 14:47:15 +03:00
}
2023-11-30 17:16:17 +02:00
std : : unique_ptr < PathFilter > filter ;
if ( filterFun )
filter = std : : make_unique < PathFilter > ( [ & ] ( const Path & p ) {
auto p2 = CanonPath ( p ) ;
return state . callPathFilter ( filterFun , { path . accessor , p2 } , p2 . abs ( ) , pos ) ;
} ) ;
2010-04-07 16:55:46 +03:00
2021-10-07 14:47:15 +03:00
std : : optional < StorePath > expectedStorePath ;
if ( expectedHash )
2024-04-13 19:10:12 +03:00
expectedStorePath = state . store - > makeFixedOutputPathFromCA ( name , ContentAddressWithReferences : : fromParts (
method ,
* expectedHash ,
{ } ) ) ;
2015-02-23 15:41:53 +02:00
2021-10-07 14:47:15 +03:00
if ( ! expectedHash | | ! state . store - > isValidPath ( * expectedStorePath ) ) {
2024-02-20 11:36:36 +02:00
auto dstPath = fetchToStore (
* state . store ,
path . resolveSymlinks ( ) ,
settings . readOnlyMode ? FetchMode : : DryRun : FetchMode : : Copy ,
name ,
method ,
filter . get ( ) ,
state . repair ) ;
2022-02-27 16:59:34 +02:00
if ( expectedHash & & expectedStorePath ! = dstPath )
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 < EvalError > (
" store path mismatch in (possibly filtered) path added from '%s' " ,
path
) . atPos ( pos ) . debugThrow ( ) ;
2022-02-27 16:59:34 +02:00
state . allowAndSetStorePathString ( dstPath , v ) ;
2021-10-07 14:47:15 +03:00
} else
2022-02-27 16:59:34 +02:00
state . allowAndSetStorePathString ( * expectedStorePath , v ) ;
2021-10-07 14:47:15 +03:00
} catch ( Error & e ) {
2022-03-04 20:31:59 +02:00
e . addTrace ( state . positions [ pos ] , " while adding path '%s' " , path ) ;
2021-10-07 14:47:15 +03:00
throw ;
}
2006-09-22 17:55:19 +03:00
}
2022-03-04 20:31:59 +02:00
static void prim_filterSource ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-01-25 17:05:57 +02:00
{
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-04-06 14:15:50 +03:00
auto path = state . coerceToPath ( pos , * args [ 1 ] , context ,
2023-10-18 18:34:58 +03:00
" while evaluating the second argument (the path to filter) passed to 'builtins.filterSource' " ) ;
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.filterSource " ) ;
2023-11-30 17:16:17 +02:00
2024-05-17 02:08:28 +03:00
addPath ( state , pos , path . baseName ( ) , path , args [ 0 ] , ContentAddressMethod : : Raw : : NixArchive , std : : nullopt , v , context ) ;
2018-01-25 17:05:57 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_filterSource ( {
. name = " __filterSource " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
2021-09-22 21:58:21 +03:00
> * * Warning * *
>
> ` filterSource ` should not be used to filter store paths . Since
> ` filterSource ` uses the name of the input directory while naming
> the output directory , doing so will produce a directory name in
> the form of ` < hash2 > - < hash > - < name > ` , where ` < hash > - < name > ` is
> the name of the input directory . Since ` < hash > ` depends on the
> unfiltered directory , the name of the output directory will
> indirectly depend on files that are filtered out by the
> function . This will trigger a rebuild even when a filtered out
> file is changed . Use ` builtins . path ` instead , which allows
> specifying the name of the output directory .
2020-08-24 15:31:10 +03:00
This function allows you to copy sources into the Nix store while
filtering certain files . For instance , suppose that you want to use
the directory ` source - dir ` as an input to a Nix expression , e . g .
` ` ` nix
stdenv . mkDerivation {
. . .
src = . / source - dir ;
}
` ` `
However , if ` source - dir ` is a Subversion working copy , then all
those annoying ` . svn ` subdirectories will also be copied to the
store . Worse , the contents of those directories may change a lot ,
causing lots of spurious rebuilds . With ` filterSource ` you can
filter out the ` . svn ` directories :
` ` ` nix
src = builtins . filterSource
( path : type : type ! = " directory " | | baseNameOf path ! = " .svn " )
. / source - dir ;
` ` `
Thus , the first argument * e1 * must be a predicate function that is
called for each regular file , directory or symlink in the source
tree * e2 * . If the function returns ` true ` , the file is copied to the
Nix store , otherwise it is omitted . The function is called with two
arguments . The first is the full path of the file . The second is a
string that identifies the type of the file , which is either
` " regular " ` , ` " directory " ` , ` " symlink " ` or ` " unknown " ` ( for other
kinds of files such as device nodes or fifos — but note that those
cannot be copied to the Nix store , so if the predicate returns
` true ` for them , the copy will fail ) . If you exclude a directory ,
the entire corresponding subtree of * e2 * will be excluded .
) " ,
. fun = prim_filterSource ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_path ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-01-25 17:05:57 +02:00
{
2023-04-06 14:15:50 +03:00
std : : optional < SourcePath > path ;
2022-02-25 17:00:00 +02:00
std : : string name ;
2018-01-25 17:05:57 +02:00
Value * filterFun = nullptr ;
2024-05-17 02:08:28 +03:00
auto method = ContentAddressMethod : : Raw : : NixArchive ;
2020-07-31 00:40:21 +03:00
std : : optional < Hash > expectedHash ;
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 ;
2018-01-25 17:05:57 +02:00
2023-04-06 14:15:50 +03:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the argument passed to 'builtins.path' " ) ;
2024-03-25 19:20:18 +02:00
for ( auto & attr : * args [ 0 ] - > attrs ( ) ) {
2022-04-22 22:45:39 +03:00
auto n = state . symbols [ attr . name ] ;
2021-10-07 14:43:17 +03:00
if ( n = = " path " )
2023-04-06 14:15:50 +03:00
path . emplace ( state . coerceToPath ( attr . pos , * attr . value , context , " while evaluating the 'path' attribute passed to 'builtins.path' " ) ) ;
2021-10-07 14:43:17 +03:00
else if ( attr . name = = state . sName )
2023-01-19 14:23:04 +02:00
name = state . forceStringNoCtx ( * attr . value , attr . pos , " while evaluating the `name` attribute passed to builtins.path " ) ;
else if ( n = = " filter " )
state . forceFunction ( * ( filterFun = attr . value ) , attr . pos , " while evaluating the `filter` parameter passed to builtins.path " ) ;
else if ( n = = " recursive " )
2024-04-13 19:10:12 +03:00
method = state . forceBool ( * attr . value , attr . pos , " while evaluating the `recursive` attribute passed to builtins.path " )
2024-05-17 02:08:28 +03:00
? ContentAddressMethod : : Raw : : NixArchive
: ContentAddressMethod : : Raw : : Flat ;
2018-01-25 17:05:57 +02:00
else if ( n = = " sha256 " )
2023-11-28 15:20:27 +02:00
expectedHash = newHashAllowEmpty ( state . forceStringNoCtx ( * attr . value , attr . pos , " while evaluating the `sha256` attribute passed to builtins.path " ) , HashAlgorithm : : SHA256 ) ;
2018-01-25 17:05:57 +02:00
else
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 < EvalError > (
" unsupported argument '%1%' to 'addPath' " ,
state . symbols [ attr . name ]
) . atPos ( attr . pos ) . debugThrow ( ) ;
2018-01-25 17:05:57 +02:00
}
2023-04-06 14:15:50 +03:00
if ( ! path )
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 < EvalError > (
" missing required 'path' attribute in the first argument to builtins.path "
) . atPos ( pos ) . debugThrow ( ) ;
2018-01-25 17:05:57 +02:00
if ( name . empty ( ) )
2023-04-06 14:15:50 +03:00
name = path - > baseName ( ) ;
2018-01-25 17:05:57 +02:00
2023-11-30 17:16:17 +02:00
addPath ( state , pos , name , * path , filterFun , method , expectedHash , v , context ) ;
2018-01-25 17:05:57 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_path ( {
. name = " __path " ,
. args = { " args " } ,
. doc = R " (
An enrichment of the built - in path type , based on the attributes
present in * args * . All are optional except ` path ` :
2021-04-23 15:30:42 +03:00
- path \
2020-08-24 15:31:10 +03:00
The underlying path .
2021-04-23 15:30:42 +03:00
- name \
2020-08-24 15:31:10 +03:00
The name of the path when added to the store . This can used to
reference paths that have nix - illegal characters in their names ,
like ` @ ` .
2021-04-23 15:30:42 +03:00
- filter \
2023-11-19 05:09:14 +02:00
A function of the type expected by [ ` builtins . filterSource ` ] ( # builtins - filterSource ) ,
2020-08-24 15:31:10 +03:00
with the same semantics .
2021-04-23 15:30:42 +03:00
- recursive \
2020-08-24 15:31:10 +03:00
When ` false ` , when ` path ` is added to the store it is with a
flat hash , rather than a hash of the NAR serialization of the
file . Thus , ` path ` must refer to a regular file , not a
directory . This allows similar behavior to ` fetchurl ` . Defaults
to ` true ` .
2021-04-23 15:30:42 +03:00
- sha256 \
2020-08-24 15:31:10 +03:00
When provided , this is the expected hash of the file at the
path . Evaluation will fail if the hash is incorrect , and
providing a hash allows ` builtins . path ` to be used even when the
` pure - eval ` nix config option is on .
) " ,
. fun = prim_path ,
} ) ;
2018-01-25 17:05:57 +02:00
2007-01-29 17:11:32 +02:00
/*************************************************************
2013-10-24 17:41:04 +03:00
* Sets
2007-01-29 17:11:32 +02:00
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2013-10-24 17:41:04 +03:00
/* Return the names of the attributes in a set as a sorted list of
strings . */
2022-03-04 20:31:59 +02:00
static void prim_attrNames ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the argument passed to builtins.attrNames " ) ;
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2024-03-25 19:20:18 +02:00
auto list = state . buildList ( args [ 0 ] - > attrs ( ) - > size ( ) ) ;
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2024-03-25 19:20:18 +02:00
for ( const auto & [ n , i ] : enumerate ( * args [ 0 ] - > attrs ( ) ) )
2024-03-14 20:10:31 +02:00
( list [ n ] = state . allocValue ( ) ) - > mkString ( state . symbols [ i . name ] ) ;
2018-02-16 05:14:35 +02:00
2024-03-14 20:10:31 +02:00
std : : sort ( list . begin ( ) , list . end ( ) ,
2023-12-10 10:25:20 +02:00
[ ] ( Value * v1 , Value * v2 ) { return strcmp ( v1 - > c_str ( ) , v2 - > c_str ( ) ) < 0 ; } ) ;
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2014-10-04 17:41:24 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_attrNames ( {
. name = " __attrNames " ,
. args = { " set " } ,
. doc = R " (
Return the names of the attributes in the set * set * in an
alphabetically sorted list . For instance , ` builtins . attrNames { y
= 1 ; x = " foo " ; } ` evaluates to ` [ " x " " y " ] ` .
) " ,
. fun = prim_attrNames ,
} ) ;
2014-10-04 17:41:24 +03:00
/* Return the values of the attributes in a set as a list, in the same
order as attrNames . */
2022-03-04 20:31:59 +02:00
static void prim_attrValues ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-10-04 17:41:24 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the argument passed to builtins.attrValues " ) ;
2014-10-04 17:41:24 +03:00
2024-03-25 19:20:18 +02:00
auto list = state . buildList ( args [ 0 ] - > attrs ( ) - > size ( ) ) ;
2014-10-04 17:41:24 +03:00
2024-03-25 19:20:18 +02:00
for ( const auto & [ n , i ] : enumerate ( * args [ 0 ] - > attrs ( ) ) )
2024-03-14 20:10:31 +02:00
list [ n ] = ( Value * ) & i ;
2014-10-04 17:41:24 +03:00
2024-03-14 20:10:31 +02:00
std : : sort ( list . begin ( ) , list . end ( ) ,
2022-03-05 15:40:24 +02:00
[ & ] ( Value * v1 , Value * v2 ) {
std : : string_view s1 = state . symbols [ ( ( Attr * ) v1 ) - > name ] ,
s2 = state . symbols [ ( ( Attr * ) v2 ) - > name ] ;
2022-01-12 19:17:59 +02:00
return s1 < s2 ;
} ) ;
2014-10-04 17:41:24 +03:00
2024-03-14 20:10:31 +02:00
for ( auto & v : list )
v = ( ( Attr * ) v ) - > value ;
v . mkList ( list ) ;
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_attrValues ( {
. name = " __attrValues " ,
. args = { " set " } ,
. doc = R " (
Return the values of the attributes in the set * set * in the order
corresponding to the sorted attribute names .
) " ,
. fun = prim_attrValues ,
} ) ;
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2007-01-29 17:11:32 +02:00
/* Dynamic version of the `.' operator. */
2022-03-04 20:31:59 +02:00
void prim_getAttr ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
{
2023-01-19 14:23:04 +02:00
auto attr = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.getAttr " ) ;
state . forceAttrs ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.getAttr " ) ;
2024-03-25 19:20:18 +02:00
auto i = getAttr (
2021-04-11 14:55:07 +03:00
state ,
2022-01-12 19:08:48 +02:00
state . symbols . create ( attr ) ,
2024-03-25 19:20:18 +02:00
args [ 1 ] - > attrs ( ) ,
2023-01-19 14:23:04 +02:00
" in the attribute set under consideration "
2021-04-11 14:55:07 +03:00
) ;
2010-05-07 15:11:05 +03:00
// !!! add to stack trace?
2022-03-04 20:31:59 +02:00
if ( state . countCalls & & i - > pos ) state . attrSelects [ i - > pos ] + + ;
2020-04-16 13:32:07 +03:00
state . forceValue ( * i - > value , pos ) ;
2010-10-24 03:41:29 +03:00
v = * i - > value ;
2007-01-29 17:11:32 +02:00
}
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_getAttr ( {
. name = " __getAttr " ,
. args = { " s " , " set " } ,
. doc = R " (
` getAttr ` returns the attribute named * s * from * set * . Evaluation
aborts if the attribute doesn ’ t exist . This is a dynamic version of
the ` . ` operator , since * s * is an expression rather than an
identifier .
) " ,
. fun = prim_getAttr ,
} ) ;
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2013-11-18 23:22:35 +02:00
/* Return position information of the specified attribute. */
2022-03-04 20:31:59 +02:00
static void prim_unsafeGetAttrPos ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2013-11-18 23:22:35 +02:00
{
2023-01-19 14:23:04 +02:00
auto attr = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.unsafeGetAttrPos " ) ;
state . forceAttrs ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.unsafeGetAttrPos " ) ;
2024-03-25 19:20:18 +02:00
auto i = args [ 1 ] - > attrs ( ) - > find ( state . symbols . create ( attr ) ) ;
if ( i = = args [ 1 ] - > attrs ( ) - > end ( ) )
2022-01-04 19:40:39 +02:00
v . mkNull ( ) ;
2013-11-18 23:22:35 +02:00
else
state . mkPos ( v , i - > pos ) ;
}
2023-05-13 20:52:45 +03:00
static RegisterPrimOp primop_unsafeGetAttrPos ( PrimOp {
2020-08-25 12:25:01 +03:00
. name = " __unsafeGetAttrPos " ,
. arity = 2 ,
. fun = prim_unsafeGetAttrPos ,
} ) ;
2013-11-18 23:22:35 +02:00
2024-01-29 07:19:23 +02:00
// access to exact position information (ie, line and colum numbers) is deferred
// due to the cost associated with calculating that information and how rarely
// it is used in practice. this is achieved by creating thunks to otherwise
// inaccessible primops that are not exposed as __op or under builtins to turn
// the internal PosIdx back into a line and column number, respectively. exposing
// these primops in any way would at best be not useful and at worst create wildly
// indeterministic eval results depending on parse order of files.
//
// in a simpler world this would instead be implemented as another kind of thunk,
// but each type of thunk has an associated runtime cost in the current evaluator.
// as with black holes this cost is too high to justify another thunk type to check
// for in the very hot path that is forceValue.
static struct LazyPosAcessors {
PrimOp primop_lineOfPos {
. arity = 1 ,
. fun = [ ] ( EvalState & state , PosIdx pos , Value * * args , Value & v ) {
2024-03-25 19:20:18 +02:00
v . mkInt ( state . positions [ PosIdx ( args [ 0 ] - > integer ( ) ) ] . line ) ;
2024-01-29 07:19:23 +02:00
}
} ;
PrimOp primop_columnOfPos {
. arity = 1 ,
. fun = [ ] ( EvalState & state , PosIdx pos , Value * * args , Value & v ) {
2024-03-25 19:20:18 +02:00
v . mkInt ( state . positions [ PosIdx ( args [ 0 ] - > integer ( ) ) ] . column ) ;
2024-01-29 07:19:23 +02:00
}
} ;
Value lineOfPos , columnOfPos ;
LazyPosAcessors ( )
{
lineOfPos . mkPrimOp ( & primop_lineOfPos ) ;
columnOfPos . mkPrimOp ( & primop_columnOfPos ) ;
}
void operator ( ) ( EvalState & state , const PosIdx pos , Value & line , Value & column )
{
Value * posV = state . allocValue ( ) ;
posV - > mkInt ( pos . id ) ;
line . mkApp ( & lineOfPos , posV ) ;
column . mkApp ( & columnOfPos , posV ) ;
}
} makeLazyPosAccessors ;
void makePositionThunks ( EvalState & state , const PosIdx pos , Value & line , Value & column )
{
makeLazyPosAccessors ( state , pos , line , column ) ;
}
2007-01-29 17:11:32 +02:00
/* Dynamic version of the `?' operator. */
2022-03-04 20:31:59 +02:00
static void prim_hasAttr ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 17:11:32 +02:00
{
2023-01-19 14:23:04 +02:00
auto attr = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.hasAttr " ) ;
state . forceAttrs ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.hasAttr " ) ;
2024-03-25 19:20:18 +02:00
v . mkBool ( args [ 1 ] - > attrs ( ) - > find ( state . symbols . create ( attr ) ) ! = args [ 1 ] - > attrs ( ) - > end ( ) ) ;
2007-01-29 17:11:32 +02:00
}
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_hasAttr ( {
. name = " __hasAttr " ,
. args = { " s " , " set " } ,
. doc = R " (
` hasAttr ` returns ` true ` if * set * has an attribute named * s * , and
` false ` otherwise . This is a dynamic version of the ` ? ` operator ,
since * s * is an expression rather than an identifier .
) " ,
. fun = prim_hasAttr ,
} ) ;
2005-08-14 17:00:39 +03:00
2013-10-24 17:41:04 +03:00
/* Determine whether the argument is a set. */
2022-03-04 20:31:59 +02:00
static void prim_isAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2010-03-31 01:39:48 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nAttrs ) ;
2010-03-31 01:39:48 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isAttrs ( {
. name = " __isAttrs " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a set , and ` false ` otherwise .
) " ,
. fun = prim_isAttrs ,
} ) ;
2010-03-31 01:39:48 +03:00
2022-03-04 20:31:59 +02:00
static void prim_removeAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2010-03-31 01:39:48 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.removeAttrs " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.removeAttrs " ) ;
2010-03-31 01:39:48 +03:00
2022-01-02 01:41:21 +02:00
/* Get the attribute names to be removed.
We keep them as Attrs instead of Symbols so std : : set_difference
can be used to remove them from attrs [ 0 ] . */
2023-11-16 14:13:01 +02:00
// 64: large enough to fit the attributes of a derivation
boost : : container : : small_vector < Attr , 64 > names ;
2022-01-02 01:41:21 +02:00
names . reserve ( args [ 1 ] - > listSize ( ) ) ;
2021-11-24 21:21:34 +02:00
for ( auto elem : args [ 1 ] - > listItems ( ) ) {
2023-01-19 14:23:04 +02:00
state . forceStringNoCtx ( * elem , pos , " while evaluating the values of the second argument passed to builtins.removeAttrs " ) ;
2023-09-26 04:30:41 +03:00
names . emplace_back ( state . symbols . create ( elem - > string_view ( ) ) , nullptr ) ;
2010-10-24 03:41:29 +03:00
}
2022-01-02 01:41:21 +02:00
std : : sort ( names . begin ( ) , names . end ( ) ) ;
2010-10-24 03:41:29 +03:00
2010-10-24 22:52:33 +03:00
/* Copy all attributes not in that set. Note that we don't need
to sort v . attrs because it ' s a subset of an already sorted
vector . */
2024-03-25 19:20:18 +02:00
auto attrs = state . buildBindings ( args [ 0 ] - > attrs ( ) - > size ( ) ) ;
2022-01-02 01:41:21 +02:00
std : : set_difference (
2024-03-25 19:20:18 +02:00
args [ 0 ] - > attrs ( ) - > begin ( ) , args [ 0 ] - > attrs ( ) - > end ( ) ,
2022-01-02 01:41:21 +02:00
names . begin ( ) , names . end ( ) ,
std : : back_inserter ( attrs ) ) ;
2022-01-04 21:29:17 +02:00
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
2010-03-31 01:39:48 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_removeAttrs ( {
. name = " removeAttrs " ,
. args = { " set " , " list " } ,
. doc = R " (
Remove the attributes listed in * list * from * set * . The attributes
don ’ t have to exist in * set * . For instance ,
` ` ` nix
removeAttrs { x = 1 ; y = 2 ; z = 3 ; } [ " a " " x " " z " ]
` ` `
evaluates to ` { y = 2 ; } ` .
) " ,
. fun = prim_removeAttrs ,
} ) ;
2010-03-31 01:39:48 +03:00
2013-10-24 17:41:04 +03:00
/* Builds a set from a list specifying (name, value) pairs. To be
precise , a list [ { name = " name1 " ; value = value1 ; } . . . { name =
" nameN " ; value = valueN ; } ] is transformed to { name1 = value1 ;
2022-01-30 10:51:39 +02:00
. . . nameN = valueN ; } . In case of duplicate occurrences of the same
2013-10-28 08:34:44 +02:00
name , the first takes precedence . */
2022-03-04 20:31:59 +02:00
static void prim_listToAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-08-19 01:12:00 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the argument passed to builtins.listToAttrs " ) ;
2010-03-31 18:38:03 +03:00
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( args [ 0 ] - > listSize ( ) ) ;
2010-03-31 18:38:03 +03:00
2010-10-24 22:52:33 +03:00
std : : set < Symbol > seen ;
2021-11-24 21:21:34 +02:00
for ( auto v2 : args [ 0 ] - > listItems ( ) ) {
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * v2 , pos , " while evaluating an element of the list passed to builtins.listToAttrs " ) ;
2013-09-02 17:29:15 +03:00
2024-03-25 19:20:18 +02:00
auto j = getAttr ( state , state . sName , v2 - > attrs ( ) , " in a {name=...; value=...;} pair " ) ;
2021-04-11 13:14:05 +03:00
2023-01-19 14:23:04 +02:00
auto name = state . forceStringNoCtx ( * j - > value , j - > pos , " while evaluating the `name` attribute of an element of the list passed to builtins.listToAttrs " ) ;
2013-09-02 17:29:15 +03:00
2022-03-05 15:40:24 +02:00
auto sym = state . symbols . create ( name ) ;
2019-10-09 16:51:52 +03:00
if ( seen . insert ( sym ) . second ) {
2024-03-25 19:20:18 +02:00
auto j2 = getAttr ( state , state . sValue , v2 - > attrs ( ) , " in a {name=...; value=...;} pair " ) ;
2022-01-04 18:39:16 +02:00
attrs . insert ( sym , j2 - > value , j2 - > pos ) ;
2010-10-24 22:52:33 +03:00
}
2007-10-09 15:51:25 +03:00
}
2010-10-24 22:52:33 +03:00
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
2007-08-19 01:12:00 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_listToAttrs ( {
. name = " __listToAttrs " ,
. args = { " e " } ,
. doc = R " (
Construct a set from a list specifying the names and values of each
attribute . Each element of the list should be a set consisting of a
string - valued attribute ` name ` specifying the name of the attribute ,
2022-12-01 18:32:45 +02:00
and an attribute ` value ` specifying its value .
In case of duplicate occurrences of the same name , the first
takes precedence .
Example :
2020-08-24 15:31:10 +03:00
` ` ` nix
builtins . listToAttrs
[ { name = " foo " ; value = 123 ; }
{ name = " bar " ; value = 456 ; }
2022-12-01 06:53:41 +02:00
{ name = " bar " ; value = 420 ; }
2020-08-24 15:31:10 +03:00
]
` ` `
evaluates to
` ` ` nix
{ foo = 123 ; bar = 456 ; }
` ` `
) " ,
. fun = prim_listToAttrs ,
} ) ;
2007-10-31 20:01:56 +02:00
2022-03-04 20:31:59 +02:00
static void prim_intersectAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.intersectAttrs " ) ;
state . forceAttrs ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.intersectAttrs " ) ;
2013-09-02 17:29:15 +03:00
2024-03-25 19:20:18 +02:00
auto & left = * args [ 0 ] - > attrs ( ) ;
auto & right = * args [ 1 ] - > attrs ( ) ;
2021-11-11 11:31:19 +02:00
auto attrs = state . buildBindings ( std : : min ( left . size ( ) , right . size ( ) ) ) ;
// The current implementation has good asymptotic complexity and is reasonably
// simple. Further optimization may be possible, but does not seem productive,
// considering the state of eval performance in 2022.
//
// I have looked for reusable and/or standard solutions and these are my
// findings:
//
// STL
// ===
// std::set_intersection is not suitable, as it only performs a simultaneous
// linear scan; not taking advantage of random access. This is O(n + m), so
// linear in the largest set, which is not acceptable for callPackage in Nixpkgs.
//
// Simultaneous scan, with alternating simple binary search
// ===
// One alternative algorithm scans the attrsets simultaneously, jumping
// forward using `lower_bound` in case of inequality. This should perform
// well on very similar sets, having a local and predictable access pattern.
// On dissimilar sets, it seems to need more comparisons than the current
// algorithm, as few consecutive attrs match. `lower_bound` could take
// advantage of the decreasing remaining search space, but this causes
// the medians to move, which can mean that they don't stay in the cache
// like they would with the current naive `find`.
//
// Double binary search
// ===
// The optimal algorithm may be "Double binary search", which doesn't
// scan at all, but rather divides both sets simultaneously.
// See "Fast Intersection Algorithms for Sorted Sequences" by Baeza-Yates et al.
// https://cs.uwaterloo.ca/~ajsaling/papers/intersection_alg_app10.pdf
// The only downsides I can think of are not having a linear access pattern
// for similar sets, and having to maintain a more intricate algorithm.
//
// Adaptive
// ===
// Finally one could run try a simultaneous scan, count misses and fall back
// to double binary search when the counter hit some threshold and/or ratio.
if ( left . size ( ) < right . size ( ) ) {
for ( auto & l : left ) {
2024-03-25 19:20:18 +02:00
auto r = right . find ( l . name ) ;
2021-11-11 11:31:19 +02:00
if ( r ! = right . end ( ) )
attrs . insert ( * r ) ;
}
}
else {
for ( auto & r : right ) {
2024-03-25 19:20:18 +02:00
auto l = left . find ( r . name ) ;
2021-11-11 11:31:19 +02:00
if ( l ! = left . end ( ) )
attrs . insert ( r ) ;
}
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
}
2022-01-04 21:29:17 +02:00
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_intersectAttrs ( {
. name = " __intersectAttrs " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
2022-09-25 09:51:09 +03:00
Return a set consisting of the attributes in the set * e2 * which have the
same name as some attribute in * e1 * .
2021-11-11 11:31:19 +02:00
Performs in O ( * n * log * m * ) where * n * is the size of the smaller set and * m * the larger set ' s size .
2020-08-24 15:31:10 +03:00
) " ,
. fun = prim_intersectAttrs ,
} ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
2022-03-04 20:31:59 +02:00
static void prim_catAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-10-04 19:15:03 +03:00
{
2023-01-19 14:23:04 +02:00
auto attrName = state . symbols . create ( state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.catAttrs " ) ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.catAttrs " ) ;
2014-10-04 19:15:03 +03:00
2023-11-20 14:38:52 +02:00
SmallValueVector < nonRecursiveStackReservation > res ( args [ 1 ] - > listSize ( ) ) ;
2022-11-18 12:13:32 +02:00
size_t found = 0 ;
2014-10-04 19:15:03 +03:00
2021-11-24 21:21:34 +02:00
for ( auto v2 : args [ 1 ] - > listItems ( ) ) {
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * v2 , pos , " while evaluating an element in the list passed as second argument to builtins.catAttrs " ) ;
2024-03-25 19:20:18 +02:00
if ( auto i = v2 - > attrs ( ) - > get ( attrName ) )
2014-10-04 19:15:03 +03:00
res [ found + + ] = i - > value ;
}
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( found ) ;
2014-10-04 19:15:03 +03:00
for ( unsigned int n = 0 ; n < found ; + + n )
2024-03-14 20:10:31 +02:00
list [ n ] = res [ n ] ;
v . mkList ( list ) ;
2014-10-04 19:15:03 +03:00
}
2020-08-25 12:16:45 +03:00
static RegisterPrimOp primop_catAttrs ( {
. name = " __catAttrs " ,
. args = { " attr " , " list " } ,
. doc = R " (
Collect each attribute named * attr * from a list of attribute
sets . Attrsets that don ' t contain the named attribute are
ignored . For example ,
2014-10-04 19:15:03 +03:00
2020-08-25 12:16:45 +03:00
` ` ` nix
builtins . catAttrs " a " [ { a = 1 ; } { b = 0 ; } { a = 2 ; } ]
` ` `
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
2020-08-25 12:16:45 +03:00
evaluates to ` [ 1 2 ] ` .
) " ,
. fun = prim_catAttrs ,
} ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
2022-03-04 20:31:59 +02:00
static void prim_functionArgs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2020-12-12 03:15:11 +02:00
if ( args [ 0 ] - > isPrimOpApp ( ) | | args [ 0 ] - > isPrimOp ( ) ) {
2022-01-04 21:29:17 +02:00
v . mkAttrs ( & state . emptyBindings ) ;
2020-05-25 20:07:38 +03:00
return ;
}
2020-12-12 03:15:11 +02:00
if ( ! args [ 0 ] - > isLambda ( ) )
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 > ( " 'functionArgs' requires a function " ) . atPos ( pos ) . debugThrow ( ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
2024-03-25 19:20:18 +02:00
if ( ! args [ 0 ] - > payload . lambda . fun - > hasFormals ( ) ) {
2022-01-04 21:29:17 +02:00
v . mkAttrs ( & state . emptyBindings ) ;
2010-10-24 23:09:37 +03:00
return ;
}
2010-04-16 18:13:47 +03:00
2024-03-25 19:20:18 +02:00
auto attrs = state . buildBindings ( args [ 0 ] - > payload . lambda . fun - > formals - > formals . size ( ) ) ;
for ( auto & i : args [ 0 ] - > payload . lambda . fun - > formals - > formals )
2024-03-21 00:11:54 +02:00
attrs . insert ( i . name , state . getBool ( i . def ) , i . pos ) ;
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_functionArgs ( {
. name = " __functionArgs " ,
. args = { " f " } ,
. doc = R " (
Return a set containing the names of the formal arguments expected
by the function * f * . The value of each attribute is a Boolean
denoting whether the corresponding argument has a default value . For
instance , ` functionArgs ( { x , y ? 123 } : . . . ) = { x = false ; y =
true ; } ` .
" Formal argument " here refers to the attributes pattern - matched by
the function . Plain lambdas are not included , e . g . ` functionArgs ( x :
. . . ) = { } ` .
) " ,
. fun = prim_functionArgs ,
} ) ;
* Two primops: builtins.intersectAttrs and builtins.functionArgs.
intersectAttrs returns the (right-biased) intersection between two
attribute sets, e.g. every attribute from the second set that also
exists in the first. functionArgs returns the set of attributes
expected by a function.
The main goal of these is to allow the elimination of most of
all-packages.nix. Most package instantiations in all-packages.nix
have this form:
foo = import ./foo.nix {
inherit a b c;
};
With intersectAttrs and functionArgs, this can be written as:
foo = callPackage (import ./foo.nix) { };
where
callPackage = f: args:
f ((builtins.intersectAttrs (builtins.functionArgs f) pkgs) // args);
I.e., foo.nix is called with all attributes from "pkgs" that it
actually needs (e.g., pkgs.a, pkgs.b and pkgs.c). (callPackage can
do any other generic package-level stuff we might want, such as
applying makeOverridable.) Of course, the automatically supplied
arguments can be overriden if needed, e.g.
foo = callPackage (import ./foo.nix) {
c = c_version_2;
};
but for the vast majority of packages, this won't be needed.
The advantages are to reduce the amount of typing needed to add a
dependency (from three sites to two), and to reduce the number of
trivial commits to all-packages.nix. For the former, there have
been two previous attempts:
- Use "args: with args;" in the package's function definition.
This however obscures the actual expected arguments of a
function, which is very bad.
- Use "{ arg1, arg2, ... }:" in the package's function definition
(i.e. use the ellipis "..." to allow arbitrary additional
arguments), and then call the function with all of "pkgs" as an
argument. But this inhibits error detection if you call it with
an misspelled (or obsolete) argument.
2009-09-15 16:01:46 +03:00
2020-08-25 12:16:45 +03:00
/* */
2022-03-04 20:31:59 +02:00
static void prim_mapAttrs ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-07-05 05:52:02 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.mapAttrs " ) ;
2018-07-05 05:52:02 +03:00
2024-03-25 19:20:18 +02:00
auto attrs = state . buildBindings ( args [ 1 ] - > attrs ( ) - > size ( ) ) ;
2018-07-05 05:52:02 +03:00
2024-03-25 19:20:18 +02:00
for ( auto & i : * args [ 1 ] - > attrs ( ) ) {
2018-07-05 18:33:12 +03:00
Value * vName = state . allocValue ( ) ;
Value * vFun2 = state . allocValue ( ) ;
2022-03-05 15:40:24 +02:00
vName - > mkString ( state . symbols [ i . name ] ) ;
2022-01-04 19:40:39 +02:00
vFun2 - > mkApp ( args [ 0 ] , vName ) ;
2022-01-04 21:29:17 +02:00
attrs . alloc ( i . name ) . mkApp ( vFun2 , i . value ) ;
2018-07-05 05:52:02 +03:00
}
2022-01-04 21:29:17 +02:00
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
2018-07-05 05:52:02 +03:00
}
2020-08-25 12:16:45 +03:00
static RegisterPrimOp primop_mapAttrs ( {
. name = " __mapAttrs " ,
. args = { " f " , " attrset " } ,
. doc = R " (
Apply function * f * to every element of * attrset * . For example ,
` ` ` nix
builtins . mapAttrs ( name : value : value * 10 ) { a = 1 ; b = 2 ; }
` ` `
evaluates to ` { a = 10 ; b = 20 ; } ` .
) " ,
. fun = prim_mapAttrs ,
} ) ;
2018-07-05 05:52:02 +03:00
2022-03-04 20:31:59 +02:00
static void prim_zipAttrsWith ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2021-12-25 16:29:49 +02:00
{
// we will first count how many values are present for each given key.
// we then allocate a single attrset and pre-populate it with lists of
// appropriate sizes, stash the pointers to the list elements of each,
// and populate the lists. after that we replace the list in the every
// attribute with the merge function application. this way we need not
// use (slightly slower) temporary storage the GC does not know about.
2024-03-14 20:10:31 +02:00
struct Item
{
size_t size = 0 ;
size_t pos = 0 ;
std : : optional < ListBuilder > list ;
} ;
std : : map < Symbol , Item > attrsSeen ;
2021-12-25 16:29:49 +02:00
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.zipAttrsWith " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.zipAttrsWith " ) ;
2024-03-14 20:10:31 +02:00
const auto listItems = args [ 1 ] - > listItems ( ) ;
2021-12-25 16:29:49 +02:00
2024-03-14 20:10:31 +02:00
for ( auto & vElem : listItems ) {
2022-11-29 01:25:36 +02:00
state . forceAttrs ( * vElem , noPos , " while evaluating a value of the list passed as second argument to builtins.zipAttrsWith " ) ;
2024-03-25 19:20:18 +02:00
for ( auto & attr : * vElem - > attrs ( ) )
2024-03-14 20:10:31 +02:00
attrsSeen . try_emplace ( attr . name ) . first - > second . size + + ;
2021-12-25 16:29:49 +02:00
}
2024-03-14 20:10:31 +02:00
for ( auto & [ sym , elem ] : attrsSeen )
elem . list . emplace ( state . buildList ( elem . size ) ) ;
2021-12-25 16:29:49 +02:00
2024-03-14 20:10:31 +02:00
for ( auto & vElem : listItems ) {
2024-03-25 19:20:18 +02:00
for ( auto & attr : * vElem - > attrs ( ) ) {
2024-03-14 20:10:31 +02:00
auto & item = attrsSeen . at ( attr . name ) ;
( * item . list ) [ item . pos + + ] = attr . value ;
}
2021-12-25 16:29:49 +02:00
}
2024-03-14 20:10:31 +02:00
auto attrs = state . buildBindings ( attrsSeen . size ( ) ) ;
for ( auto & [ sym , elem ] : attrsSeen ) {
2022-01-04 20:09:40 +02:00
auto name = state . allocValue ( ) ;
2024-03-14 20:10:31 +02:00
name - > mkString ( state . symbols [ sym ] ) ;
2022-01-04 19:40:39 +02:00
auto call1 = state . allocValue ( ) ;
call1 - > mkApp ( args [ 0 ] , name ) ;
auto call2 = state . allocValue ( ) ;
2024-03-14 20:10:31 +02:00
auto arg = state . allocValue ( ) ;
arg - > mkList ( * elem . list ) ;
call2 - > mkApp ( call1 , arg ) ;
attrs . insert ( sym , call2 ) ;
2021-12-25 16:29:49 +02:00
}
2024-03-14 20:10:31 +02:00
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
2021-12-25 16:29:49 +02:00
}
static RegisterPrimOp primop_zipAttrsWith ( {
. name = " __zipAttrsWith " ,
. args = { " f " , " list " } ,
. doc = R " (
Transpose a list of attribute sets into an attribute set of lists ,
then apply ` mapAttrs ` .
` f ` receives two arguments : the attribute name and a non - empty
list of all values encountered for that attribute name .
The result is an attribute set where the attribute names are the
union of the attribute names in each element of ` list ` . The attribute
values are the return values of ` f ` .
` ` ` nix
builtins . zipAttrsWith
( name : values : { inherit name values ; } )
[ { a = " x " ; } { a = " y " ; b = " z " ; } ]
` ` `
evaluates to
` ` `
{
a = { name = " a " ; values = [ " x " " y " ] ; } ;
b = { name = " b " ; values = [ " z " ] ; } ;
}
` ` `
) " ,
. fun = prim_zipAttrsWith ,
} ) ;
2018-07-05 05:52:02 +03:00
2007-01-29 17:11:32 +02:00
/*************************************************************
* Lists
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
* A primitive operation `dependencyClosure' to do automatic dependency
determination (e.g., finding the header files dependencies of a C
file) in Nix low-level builds automatically.
For instance, in the function `compileC' in make/lib/default.nix, we
find the header file dependencies of C file `main' as follows:
localIncludes =
dependencyClosure {
scanner = file:
import (findIncludes {
inherit file;
});
startSet = [main];
};
The function works by "growing" the set of dependencies, starting
with the set `startSet', and calling the function `scanner' for each
file to get its dependencies (which should yield a list of strings
representing relative paths). For instance, when `scanner' is
called on a file `foo.c' that includes the line
#include "../bar/fnord.h"
then `scanner' should yield ["../bar/fnord.h"]. This list of
dependencies is absolutised relative to the including file and added
to the set of dependencies. The process continues until no more
dependencies are found (hence its a closure).
`dependencyClosure' yields a list that contains in alternation a
dependency, and its relative path to the directory of the start
file, e.g.,
[ /bla/bla/foo.c
"foo.c"
/bla/bar/fnord.h
"../bar/fnord.h"
]
These relative paths are necessary for the builder that compiles
foo.c to reconstruct the relative directory structure expected by
foo.c.
The advantage of `dependencyClosure' over the old approach (using
the impure `__currentTime') is that it's completely pure, and more
efficient because it only rescans for dependencies (i.e., by
building the derivations yielded by `scanner') if sources have
actually changed. The old approach rescanned every time.
2005-08-14 15:38:47 +03:00
2007-01-29 17:11:32 +02:00
/* Determine whether the argument is a list. */
2022-03-04 20:31:59 +02:00
static void prim_isList ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-08-23 18:46:00 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( args [ 0 ] - > type ( ) = = nList ) ;
2006-08-23 18:46:00 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_isList ( {
. name = " __isList " ,
. args = { " e " } ,
. doc = R " (
Return ` true ` if * e * evaluates to a list , and ` false ` otherwise .
) " ,
. fun = prim_isList ,
} ) ;
2006-08-23 18:46:00 +03:00
2022-03-04 20:31:59 +02:00
static void elemAt ( EvalState & state , const PosIdx pos , Value & list , int n , Value & v )
2012-08-13 20:46:42 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( list , pos , " while evaluating the first argument passed to builtins.elemAt " ) ;
2015-07-23 23:05:09 +03:00
if ( n < 0 | | ( unsigned int ) n > = list . listSize ( ) )
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 < EvalError > (
" list index %1% is out of bounds " ,
n
) . atPos ( pos ) . debugThrow ( ) ;
2020-04-16 13:32:07 +03:00
state . forceValue ( * list . listElems ( ) [ n ] , pos ) ;
2015-07-23 23:05:09 +03:00
v = * list . listElems ( ) [ n ] ;
2012-08-13 20:46:42 +03:00
}
/* Return the n-1'th element of a list. */
2022-03-04 20:31:59 +02:00
static void prim_elemAt ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2012-08-13 20:46:42 +03:00
{
2023-01-19 14:23:04 +02:00
elemAt ( state , pos , * args [ 0 ] , state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.elemAt " ) , v ) ;
2012-08-13 20:46:42 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_elemAt ( {
. name = " __elemAt " ,
. args = { " xs " , " n " } ,
. doc = R " (
Return element * n * from the list * xs * . Elements are counted starting
from 0. A fatal error occurs if the index is out of bounds .
) " ,
. fun = prim_elemAt ,
} ) ;
2012-08-13 20:46:42 +03:00
2006-09-22 17:46:36 +03:00
/* Return the first element of a list. */
2022-03-04 20:31:59 +02:00
static void prim_head ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-22 17:46:36 +03:00
{
2014-04-04 19:51:01 +03:00
elemAt ( state , pos , * args [ 0 ] , 0 , v ) ;
2006-09-22 17:46:36 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_head ( {
. name = " __head " ,
. args = { " list " } ,
. doc = R " (
Return the first element of a list ; abort evaluation if the argument
isn ’ t a list or is an empty list . You can test whether a list is
empty by comparing it with ` [ ] ` .
) " ,
. fun = prim_head ,
} ) ;
2006-09-22 17:46:36 +03:00
2015-03-06 17:39:48 +02:00
/* Return a list consisting of everything but the first element of
2012-08-13 08:05:35 +03:00
a list . Warning : this function takes O ( n ) time , so you probably
don ' t want to use it ! */
2022-03-04 20:31:59 +02:00
static void prim_tail ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-22 17:46:36 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.tail " ) ;
2015-07-23 23:05:09 +03:00
if ( args [ 0 ] - > listSize ( ) = = 0 )
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 < EvalError > ( " 'tail' called on an empty list " ) . atPos ( pos ) . debugThrow ( ) ;
2020-05-09 03:18:28 +03:00
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( args [ 0 ] - > listSize ( ) - 1 ) ;
for ( const auto & [ n , v ] : enumerate ( list ) )
v = args [ 0 ] - > listElems ( ) [ n + 1 ] ;
v . mkList ( list ) ;
2006-09-22 17:46:36 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_tail ( {
. name = " __tail " ,
. args = { " list " } ,
. doc = R " (
2023-09-25 16:39:11 +03:00
Return the list without its first item ; abort evaluation if
2020-08-24 15:31:10 +03:00
the argument isn ’ t a list or is an empty list .
> * * Warning * *
2021-09-22 21:58:21 +03:00
>
2020-08-24 15:31:10 +03:00
> This function should generally be avoided since it ' s inefficient :
> unlike Haskell ' s ` tail ` , it takes O ( n ) time , so recursing over a
> list by repeatedly calling ` tail ` takes O ( n ^ 2 ) time .
) " ,
. fun = prim_tail ,
} ) ;
2006-09-22 17:46:36 +03:00
2004-08-04 13:59:20 +03:00
/* Apply a function to every element of a list. */
2022-03-04 20:31:59 +02:00
static void prim_map ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2004-08-04 13:59:20 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.map " ) ;
2022-03-04 06:04:47 +02:00
2023-01-19 14:23:04 +02:00
if ( args [ 1 ] - > listSize ( ) = = 0 ) {
v = * args [ 1 ] ;
return ;
}
2023-01-18 02:19:07 +02:00
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.map " ) ;
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( args [ 1 ] - > listSize ( ) ) ;
for ( const auto & [ n , v ] : enumerate ( list ) )
( v = state . allocValue ( ) ) - > mkApp (
2022-03-18 01:58:09 +02:00
args [ 0 ] , args [ 1 ] - > listElems ( ) [ n ] ) ;
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2004-08-04 13:59:20 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_map ( {
. name = " map " ,
. args = { " f " , " list " } ,
. doc = R " (
Apply the function * f * to each element in the list * list * . For
example ,
` ` ` nix
2023-01-07 07:04:43 +02:00
map ( x : " foo " + x ) [ " bar " " bla " " abc " ]
2020-08-24 15:31:10 +03:00
` ` `
evaluates to ` [ " foobar " " foobla " " fooabc " ] ` .
) " ,
. fun = prim_map ,
} ) ;
2004-08-04 13:59:20 +03:00
2012-08-13 07:28:08 +03:00
/* Filter a list using a predicate; that is, return a list containing
every element from the list for which the predicate function
returns true . */
2022-03-04 20:31:59 +02:00
static void prim_filter ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2012-08-13 07:28:08 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.filter " ) ;
if ( args [ 1 ] - > listSize ( ) = = 0 ) {
v = * args [ 1 ] ;
return ;
}
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.filter " ) ;
2012-08-13 07:28:08 +03:00
2023-11-20 14:38:52 +02:00
SmallValueVector < nonRecursiveStackReservation > vs ( args [ 1 ] - > listSize ( ) ) ;
2022-11-18 12:13:32 +02:00
size_t k = 0 ;
2012-08-13 07:28:08 +03:00
2012-12-04 18:22:20 +02:00
bool same = true ;
2015-07-23 23:05:09 +03:00
for ( unsigned int n = 0 ; n < args [ 1 ] - > listSize ( ) ; + + n ) {
2012-08-13 07:28:08 +03:00
Value res ;
2015-07-23 23:05:09 +03:00
state . callFunction ( * args [ 0 ] , * args [ 1 ] - > listElems ( ) [ n ] , res , noPos ) ;
2023-01-19 14:23:04 +02:00
if ( state . forceBool ( res , pos , " while evaluating the return value of the filtering function passed to builtins.filter " ) )
2015-07-23 23:05:09 +03:00
vs [ k + + ] = args [ 1 ] - > listElems ( ) [ n ] ;
2012-12-04 18:22:20 +02:00
else
same = false ;
2012-08-13 07:28:08 +03:00
}
2012-12-04 18:22:20 +02:00
if ( same )
v = * args [ 1 ] ;
else {
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( k ) ;
for ( const auto & [ n , v ] : enumerate ( list ) ) v = vs [ n ] ;
v . mkList ( list ) ;
2012-12-04 18:22:20 +02:00
}
2012-08-13 07:28:08 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_filter ( {
. name = " __filter " ,
. args = { " f " , " list " } ,
. doc = R " (
Return a list consisting of the elements of * list * for which the
function * f * returns ` true ` .
) " ,
. fun = prim_filter ,
} ) ;
2012-08-13 07:28:08 +03:00
2012-08-13 08:53:10 +03:00
/* Return true if a list contains a given element. */
2022-03-04 20:31:59 +02:00
static void prim_elem ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2012-08-13 08:05:35 +03:00
{
bool res = false ;
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.elem " ) ;
2021-11-24 21:21:34 +02:00
for ( auto elem : args [ 1 ] - > listItems ( ) )
2023-01-19 14:23:04 +02:00
if ( state . eqValues ( * args [ 0 ] , * elem , pos , " while searching for the presence of the given element in the list " ) ) {
2012-08-13 08:05:35 +03:00
res = true ;
break ;
}
2022-01-04 19:40:39 +02:00
v . mkBool ( res ) ;
2012-08-13 08:05:35 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_elem ( {
. name = " __elem " ,
. args = { " x " , " xs " } ,
. doc = R " (
Return ` true ` if a value equal to * x * occurs in the list * xs * , and
` false ` otherwise .
) " ,
. fun = prim_elem ,
} ) ;
2012-08-13 08:05:35 +03:00
2012-08-13 08:53:10 +03:00
/* Concatenate a list of lists. */
2022-03-04 20:31:59 +02:00
static void prim_concatLists ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2012-08-13 08:53:10 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.concatLists " ) ;
state . concatLists ( v , args [ 0 ] - > listSize ( ) , args [ 0 ] - > listElems ( ) , pos , " while evaluating a value of the list passed to builtins.concatLists " ) ;
2012-08-13 08:53:10 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_concatLists ( {
. name = " __concatLists " ,
. args = { " lists " } ,
. doc = R " (
Concatenate a list of lists into a single list .
) " ,
. fun = prim_concatLists ,
} ) ;
2012-08-13 08:53:10 +03:00
2008-07-11 16:29:04 +03:00
/* Return the length of a list. This is an O(1) time operation. */
2022-03-04 20:31:59 +02:00
static void prim_length ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-07-11 16:29:04 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.length " ) ;
2022-01-04 19:40:39 +02:00
v . mkInt ( args [ 0 ] - > listSize ( ) ) ;
2008-07-11 16:29:04 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_length ( {
. name = " __length " ,
. args = { " e " } ,
. doc = R " (
Return the length of the list * e * .
) " ,
. fun = prim_length ,
} ) ;
2008-07-11 16:29:04 +03:00
2015-07-23 18:03:02 +03:00
/* Reduce a list by applying a binary operator, from left to
right . The operator is applied strictly . */
2022-03-04 20:31:59 +02:00
static void prim_foldlStrict ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-23 18:03:02 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.foldlStrict " ) ;
state . forceList ( * args [ 2 ] , pos , " while evaluating the third argument passed to builtins.foldlStrict " ) ;
2015-07-23 18:03:02 +03:00
2018-07-21 09:44:42 +03:00
if ( args [ 2 ] - > listSize ( ) ) {
Value * vCur = args [ 1 ] ;
2015-07-23 18:03:02 +03:00
2021-11-24 21:21:34 +02:00
for ( auto [ n , elem ] : enumerate ( args [ 2 ] - > listItems ( ) ) ) {
Value * vs [ ] { vCur , elem } ;
2015-07-23 23:05:09 +03:00
vCur = n = = args [ 2 ] - > listSize ( ) - 1 ? & v : state . allocValue ( ) ;
2020-03-02 18:22:31 +02:00
state . callFunction ( * args [ 0 ] , 2 , vs , * vCur , pos ) ;
2015-07-23 18:03:02 +03:00
}
2020-04-16 13:32:07 +03:00
state . forceValue ( v , pos ) ;
2018-07-21 09:44:42 +03:00
} else {
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 1 ] , pos ) ;
2018-07-21 09:44:42 +03:00
v = * args [ 1 ] ;
}
2015-07-23 18:03:02 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_foldlStrict ( {
. name = " __foldl' " ,
. args = { " op " , " nul " , " list " } ,
. doc = R " (
Reduce a list by applying a binary operator , from left to right ,
2021-11-22 14:35:35 +02:00
e . g . ` foldl ' op nul [ x0 x1 x2 . . . ] = op ( op ( op nul x0 ) x1 ) x2 )
2023-11-23 23:02:20 +02:00
. . . ` .
For example , ` foldl ' ( acc : elem : acc + elem ) 0 [ 1 2 3 ] ` evaluates
to ` 6 ` and ` foldl ' ( acc : elem : { " ${elem} " = elem ; } // acc) {}
[ " a " " b " ] ` evaluates to ` { a = " a " ; b = " b " ; } ` .
2023-11-24 11:50:01 +02:00
The first argument of ` op ` is the accumulator whereas the second
2023-11-23 23:02:20 +02:00
argument is the current element being processed . The return value
of each application of ` op ` is evaluated immediately , even for
intermediate values .
2020-08-24 15:31:10 +03:00
) " ,
. fun = prim_foldlStrict ,
} ) ;
2015-07-23 18:03:02 +03:00
2022-03-04 20:31:59 +02:00
static void anyOrAll ( bool any , EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-23 20:23:11 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , std : : string ( " while evaluating the first argument passed to builtins. " ) + ( any ? " any " : " all " ) ) ;
state . forceList ( * args [ 1 ] , pos , std : : string ( " while evaluating the second argument passed to builtins. " ) + ( any ? " any " : " all " ) ) ;
2015-07-23 20:23:11 +03:00
2023-11-16 13:18:37 +02:00
std : : string_view errorCtx = any
? " while evaluating the return value of the function passed to builtins.any "
: " while evaluating the return value of the function passed to builtins.all " ;
2015-07-23 20:23:11 +03:00
Value vTmp ;
2021-11-24 21:21:34 +02:00
for ( auto elem : args [ 1 ] - > listItems ( ) ) {
state . callFunction ( * args [ 0 ] , * elem , vTmp , pos ) ;
2023-11-16 13:18:37 +02:00
bool res = state . forceBool ( vTmp , pos , errorCtx ) ;
2015-07-23 20:23:11 +03:00
if ( res = = any ) {
2022-01-04 19:40:39 +02:00
v . mkBool ( any ) ;
2015-07-23 20:23:11 +03:00
return ;
}
}
2022-01-04 19:40:39 +02:00
v . mkBool ( ! any ) ;
2015-07-23 20:23:11 +03:00
}
2022-03-04 20:31:59 +02:00
static void prim_any ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-23 20:23:11 +03:00
{
anyOrAll ( true , state , pos , args , v ) ;
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_any ( {
. name = " __any " ,
. args = { " pred " , " list " } ,
. doc = R " (
Return ` true ` if the function * pred * returns ` true ` for at least one
element of * list * , and ` false ` otherwise .
) " ,
. fun = prim_any ,
} ) ;
2015-07-23 20:23:11 +03:00
2022-03-04 20:31:59 +02:00
static void prim_all ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-23 20:23:11 +03:00
{
anyOrAll ( false , state , pos , args , v ) ;
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_all ( {
. name = " __all " ,
. args = { " pred " , " list " } ,
. doc = R " (
Return ` true ` if the function * pred * returns ` true ` for all elements
of * list * , and ` false ` otherwise .
) " ,
. fun = prim_all ,
} ) ;
2015-07-23 20:23:11 +03:00
2022-03-04 20:31:59 +02:00
static void prim_genList ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-28 18:27:32 +03:00
{
2023-01-19 14:23:04 +02:00
auto len = state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.genList " ) ;
2015-07-28 18:27:32 +03:00
if ( len < 0 )
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 < EvalError > ( " cannot create list of size %1% " , len ) . atPos ( pos ) . debugThrow ( ) ;
2015-07-28 18:27:32 +03:00
2022-11-29 01:25:36 +02:00
// More strict than striclty (!) necessary, but acceptable
// as evaluating map without accessing any values makes little sense.
state . forceFunction ( * args [ 0 ] , noPos , " while evaluating the first argument passed to builtins.genList " ) ;
2015-07-28 18:27:32 +03:00
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( len ) ;
for ( const auto & [ n , v ] : enumerate ( list ) ) {
2022-01-04 19:40:39 +02:00
auto arg = state . allocValue ( ) ;
arg - > mkInt ( n ) ;
2024-03-14 20:10:31 +02:00
( v = state . allocValue ( ) ) - > mkApp ( args [ 0 ] , arg ) ;
2015-07-28 18:27:32 +03:00
}
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2015-07-28 18:27:32 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_genList ( {
. name = " __genList " ,
. args = { " generator " , " length " } ,
. doc = R " (
Generate list of size * length * , with each element * i * equal to the
value returned by * generator * ` i ` . For example ,
` ` ` nix
builtins . genList ( x : x * x ) 5
` ` `
returns the list ` [ 0 1 4 9 16 ] ` .
) " ,
. fun = prim_genList ,
} ) ;
2015-07-28 18:27:32 +03:00
2022-03-04 20:31:59 +02:00
static void prim_lessThan ( EvalState & state , const PosIdx pos , Value * * args , Value & v ) ;
2015-07-28 19:39:00 +03:00
2022-03-04 20:31:59 +02:00
static void prim_sort ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-28 19:39:00 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.sort " ) ;
2015-07-28 19:39:00 +03:00
auto len = args [ 1 ] - > listSize ( ) ;
2023-01-19 14:23:04 +02:00
if ( len = = 0 ) {
v = * args [ 1 ] ;
return ;
}
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.sort " ) ;
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( len ) ;
for ( const auto & [ n , v ] : enumerate ( list ) )
state . forceValue ( * ( v = args [ 1 ] - > listElems ( ) [ n ] ) , pos ) ;
2015-07-28 19:39:00 +03:00
auto comparator = [ & ] ( Value * a , Value * b ) {
/* Optimization: if the comparator is lessThan, bypass
callFunction . */
2023-08-28 19:20:23 +03:00
if ( args [ 0 ] - > isPrimOp ( ) ) {
2024-04-17 17:02:44 +03:00
auto ptr = args [ 0 ] - > primOp ( ) - > fun . target < decltype ( & prim_lessThan ) > ( ) ;
2023-08-28 19:20:23 +03:00
if ( ptr & & * ptr = = prim_lessThan )
return CompareValues ( state , noPos , " while evaluating the ordering function passed to builtins.sort " ) ( a , b ) ;
}
2015-07-28 19:39:00 +03:00
2020-03-02 18:22:31 +02:00
Value * vs [ ] = { a , b } ;
Value vBool ;
2023-01-19 14:23:04 +02:00
state . callFunction ( * args [ 0 ] , 2 , vs , vBool , noPos ) ;
return state . forceBool ( vBool , pos , " while evaluating the return value of the sorting function passed to builtins.sort " ) ;
2015-07-28 19:39:00 +03:00
} ;
/* FIXME: std::sort can segfault if the comparator is not a strict
weak ordering . What to do ? std : : stable_sort ( ) seems more
resilient , but no guarantees . . . */
2024-03-15 19:22:39 +02:00
std : : stable_sort ( list . begin ( ) , list . end ( ) , comparator ) ;
v . mkList ( list ) ;
2015-07-28 19:39:00 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_sort ( {
. name = " __sort " ,
. args = { " comparator " , " list " } ,
. doc = R " (
Return * list * in sorted order . It repeatedly calls the function
* comparator * with two elements . The comparator should return ` true `
if the first element is less than the second , and ` false ` otherwise .
For example ,
` ` ` nix
builtins . sort builtins . lessThan [ 483 249 526 147 42 77 ]
` ` `
produces the list ` [ 42 77 147 249 483 526 ] ` .
This is a stable sort : it preserves the relative order of elements
deemed equal by the comparator .
) " ,
. fun = prim_sort ,
} ) ;
2015-07-28 19:39:00 +03:00
2022-03-04 20:31:59 +02:00
static void prim_partition ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2016-08-29 18:28:20 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.partition " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.partition " ) ;
2016-08-29 18:28:20 +03:00
auto len = args [ 1 ] - > listSize ( ) ;
ValueVector right , wrong ;
for ( unsigned int n = 0 ; n < len ; + + n ) {
auto vElem = args [ 1 ] - > listElems ( ) [ n ] ;
2020-04-16 13:32:07 +03:00
state . forceValue ( * vElem , pos ) ;
2016-08-29 18:28:20 +03:00
Value res ;
state . callFunction ( * args [ 0 ] , * vElem , res , pos ) ;
2023-01-19 14:23:04 +02:00
if ( state . forceBool ( res , pos , " while evaluating the return value of the partition function passed to builtins.partition " ) )
2016-08-29 18:28:20 +03:00
right . push_back ( vElem ) ;
else
wrong . push_back ( vElem ) ;
}
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( 2 ) ;
2016-08-29 18:28:20 +03:00
2018-03-15 05:53:43 +02:00
auto rsize = right . size ( ) ;
2024-03-14 20:10:31 +02:00
auto rlist = state . buildList ( rsize ) ;
2018-03-15 05:53:43 +02:00
if ( rsize )
2024-03-14 20:10:31 +02:00
memcpy ( rlist . elems , right . data ( ) , sizeof ( Value * ) * rsize ) ;
attrs . alloc ( state . sRight ) . mkList ( rlist ) ;
2016-08-29 18:28:20 +03:00
2018-03-15 05:53:43 +02:00
auto wsize = wrong . size ( ) ;
2024-03-14 20:10:31 +02:00
auto wlist = state . buildList ( wsize ) ;
2018-03-15 05:53:43 +02:00
if ( wsize )
2024-03-14 20:10:31 +02:00
memcpy ( wlist . elems , wrong . data ( ) , sizeof ( Value * ) * wsize ) ;
attrs . alloc ( state . sWrong ) . mkList ( wlist ) ;
2016-08-29 18:28:20 +03:00
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
2016-08-29 18:28:20 +03:00
}
2020-08-25 12:16:45 +03:00
static RegisterPrimOp primop_partition ( {
. name = " __partition " ,
. args = { " pred " , " list " } ,
. doc = R " (
Given a predicate function * pred * , this function returns an
attrset containing a list named ` right ` , containing the elements
in * list * for which * pred * returned ` true ` , and a list named
` wrong ` , containing the elements for which it returned
` false ` . For example ,
` ` ` nix
builtins . partition ( x : x > 10 ) [ 1 23 9 3 42 ]
` ` `
evaluates to
` ` ` nix
{ right = [ 23 42 ] ; wrong = [ 1 9 3 ] ; }
` ` `
) " ,
. fun = prim_partition ,
} ) ;
2016-08-29 18:28:20 +03:00
2022-03-04 20:31:59 +02:00
static void prim_groupBy ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2021-12-02 18:46:44 +02:00
{
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.groupBy " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.groupBy " ) ;
2021-12-02 18:46:44 +02:00
ValueVectorMap attrs ;
for ( auto vElem : args [ 1 ] - > listItems ( ) ) {
Value res ;
state . callFunction ( * args [ 0 ] , * vElem , res , pos ) ;
2023-01-19 14:23:04 +02:00
auto name = state . forceStringNoCtx ( res , pos , " while evaluating the return value of the grouping function passed to builtins.groupBy " ) ;
2022-03-05 15:40:24 +02:00
auto sym = state . symbols . create ( name ) ;
2021-12-02 18:46:44 +02:00
auto vector = attrs . try_emplace ( sym , ValueVector ( ) ) . first ;
vector - > second . push_back ( vElem ) ;
}
2022-01-04 21:29:17 +02:00
auto attrs2 = state . buildBindings ( attrs . size ( ) ) ;
2021-12-02 18:46:44 +02:00
for ( auto & i : attrs ) {
auto size = i . second . size ( ) ;
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( size ) ;
memcpy ( list . elems , i . second . data ( ) , sizeof ( Value * ) * size ) ;
attrs2 . alloc ( i . first ) . mkList ( list ) ;
2021-12-02 18:46:44 +02:00
}
2022-01-04 21:29:17 +02:00
v . mkAttrs ( attrs2 . alreadySorted ( ) ) ;
2021-12-02 18:46:44 +02:00
}
static RegisterPrimOp primop_groupBy ( {
. name = " __groupBy " ,
. args = { " f " , " list " } ,
. doc = R " (
Groups elements of * list * together by the string returned from the
function * f * called on each element . It returns an attribute set
where each attribute value contains the elements of * list * that are
mapped to the same corresponding attribute name returned by * f * .
For example ,
` ` ` nix
builtins . groupBy ( builtins . substring 0 1 ) [ " foo " " bar " " baz " ]
` ` `
evaluates to
` ` ` nix
{ b = [ " bar " " baz " ] ; f = [ " foo " ] ; }
` ` `
) " ,
. fun = prim_groupBy ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_concatMap ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-07-05 05:52:02 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceFunction ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.concatMap " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.concatMap " ) ;
2018-07-05 15:37:37 +03:00
auto nrLists = args [ 1 ] - > listSize ( ) ;
2018-07-05 05:52:02 +03:00
2023-11-20 14:38:52 +02:00
// List of returned lists before concatenation. References to these Values must NOT be persisted.
SmallTemporaryValueVector < conservativeStackReservation > lists ( nrLists ) ;
2018-07-05 15:37:37 +03:00
size_t len = 0 ;
2018-07-05 05:52:02 +03:00
2018-07-05 15:37:37 +03:00
for ( unsigned int n = 0 ; n < nrLists ; + + n ) {
2018-07-05 05:52:02 +03:00
Value * vElem = args [ 1 ] - > listElems ( ) [ n ] ;
2018-07-05 15:37:37 +03:00
state . callFunction ( * args [ 0 ] , * vElem , lists [ n ] , pos ) ;
2023-11-19 20:57:07 +02:00
state . forceList ( lists [ n ] , lists [ n ] . determinePos ( args [ 0 ] - > determinePos ( pos ) ) , " while evaluating the return value of the function passed to builtins.concatMap " ) ;
2018-07-05 15:37:37 +03:00
len + = lists [ n ] . listSize ( ) ;
2018-07-05 05:52:02 +03:00
}
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( len ) ;
auto out = list . elems ;
2018-07-05 15:37:37 +03:00
for ( unsigned int n = 0 , pos = 0 ; n < nrLists ; + + n ) {
auto l = lists [ n ] . listSize ( ) ;
if ( l )
memcpy ( out + pos , lists [ n ] . listElems ( ) , l * sizeof ( Value * ) ) ;
pos + = l ;
}
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2018-07-05 05:52:02 +03:00
}
2020-08-25 12:16:45 +03:00
static RegisterPrimOp primop_concatMap ( {
. name = " __concatMap " ,
. args = { " f " , " list " } ,
. doc = R " (
This function is equivalent to ` builtins . concatLists ( map f list ) `
but is more efficient .
) " ,
. fun = prim_concatMap ,
} ) ;
2018-07-05 05:52:02 +03:00
2007-01-29 17:11:32 +02:00
/*************************************************************
* Integer arithmetic
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2005-08-14 17:00:39 +03:00
2022-03-04 20:31:59 +02:00
static void prim_add ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-22 18:29:21 +03:00
{
2018-08-19 12:59:49 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2020-12-17 15:45:45 +02:00
if ( args [ 0 ] - > type ( ) = = nFloat | | args [ 1 ] - > type ( ) = = nFloat )
2023-01-19 14:23:04 +02:00
v . mkFloat ( state . forceFloat ( * args [ 0 ] , pos , " while evaluating the first argument of the addition " )
+ state . forceFloat ( * args [ 1 ] , pos , " while evaluating the second argument of the addition " ) ) ;
2016-01-05 01:40:40 +02:00
else
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument of the addition " )
+ state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument of the addition " ) ) ;
2006-09-22 18:29:21 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_add ( {
. name = " __add " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the sum of the numbers * e1 * and * e2 * .
) " ,
. fun = prim_add ,
} ) ;
2006-09-22 18:29:21 +03:00
2022-03-04 20:31:59 +02:00
static void prim_sub ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 16:23:09 +02:00
{
2018-08-19 12:59:49 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2020-12-17 15:45:45 +02:00
if ( args [ 0 ] - > type ( ) = = nFloat | | args [ 1 ] - > type ( ) = = nFloat )
2023-01-19 14:23:04 +02:00
v . mkFloat ( state . forceFloat ( * args [ 0 ] , pos , " while evaluating the first argument of the subtraction " )
- state . forceFloat ( * args [ 1 ] , pos , " while evaluating the second argument of the subtraction " ) ) ;
2016-01-05 01:40:40 +02:00
else
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument of the subtraction " )
- state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument of the subtraction " ) ) ;
2007-01-29 16:23:09 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_sub ( {
. name = " __sub " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the difference between the numbers * e1 * and * e2 * .
) " ,
. fun = prim_sub ,
} ) ;
2007-01-29 16:23:09 +02:00
2022-03-04 20:31:59 +02:00
static void prim_mul ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-07-11 16:29:04 +03:00
{
2018-08-19 12:59:49 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2020-12-17 15:45:45 +02:00
if ( args [ 0 ] - > type ( ) = = nFloat | | args [ 1 ] - > type ( ) = = nFloat )
2023-01-19 14:23:04 +02:00
v . mkFloat ( state . forceFloat ( * args [ 0 ] , pos , " while evaluating the first of the multiplication " )
* state . forceFloat ( * args [ 1 ] , pos , " while evaluating the second argument of the multiplication " ) ) ;
2016-01-05 01:40:40 +02:00
else
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument of the multiplication " )
* state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument of the multiplication " ) ) ;
2008-07-11 16:29:04 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_mul ( {
. name = " __mul " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the product of the numbers * e1 * and * e2 * .
) " ,
. fun = prim_mul ,
} ) ;
2008-07-11 16:29:04 +03:00
2022-03-04 20:31:59 +02:00
static void prim_div ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-07-11 16:29:04 +03:00
{
2018-08-19 12:59:49 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2023-01-19 14:23:04 +02:00
NixFloat f2 = state . forceFloat ( * args [ 1 ] , pos , " while evaluating the second operand of the division " ) ;
2020-06-15 15:06:58 +03:00
if ( f2 = = 0 )
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 < EvalError > ( " division by zero " ) . atPos ( pos ) . debugThrow ( ) ;
2016-01-05 01:40:40 +02:00
2020-12-17 15:45:45 +02:00
if ( args [ 0 ] - > type ( ) = = nFloat | | args [ 1 ] - > type ( ) = = nFloat ) {
2023-01-19 14:23:04 +02:00
v . mkFloat ( state . forceFloat ( * args [ 0 ] , pos , " while evaluating the first operand of the division " ) / f2 ) ;
2016-10-26 18:09:01 +03:00
} else {
2023-01-19 14:23:04 +02:00
NixInt i1 = state . forceInt ( * args [ 0 ] , pos , " while evaluating the first operand of the division " ) ;
NixInt i2 = state . forceInt ( * args [ 1 ] , pos , " while evaluating the second operand of the division " ) ;
2016-10-26 18:09:01 +03:00
/* Avoid division overflow as it might raise SIGFPE. */
if ( i1 = = std : : numeric_limits < NixInt > : : min ( ) & & i2 = = - 1 )
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 < EvalError > ( " overflow in integer division " ) . atPos ( pos ) . debugThrow ( ) ;
2020-05-09 03:18:28 +03:00
2022-01-04 19:40:39 +02:00
v . mkInt ( i1 / i2 ) ;
2016-10-26 18:09:01 +03:00
}
2008-07-11 16:29:04 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_div ( {
. name = " __div " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the quotient of the numbers * e1 * and * e2 * .
) " ,
. fun = prim_div ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_bitAnd ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-05-12 19:50:39 +03:00
{
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.bitAnd " )
& state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.bitAnd " ) ) ;
2018-05-12 19:50:39 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_bitAnd ( {
. name = " __bitAnd " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the bitwise AND of the integers * e1 * and * e2 * .
) " ,
. fun = prim_bitAnd ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_bitOr ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-05-12 19:50:39 +03:00
{
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.bitOr " )
| state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.bitOr " ) ) ;
2018-05-12 19:50:39 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_bitOr ( {
. name = " __bitOr " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the bitwise OR of the integers * e1 * and * e2 * .
) " ,
. fun = prim_bitOr ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_bitXor ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-05-12 19:50:39 +03:00
{
2023-01-19 14:23:04 +02:00
v . mkInt ( state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.bitXor " )
^ state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.bitXor " ) ) ;
2018-05-12 19:50:39 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_bitXor ( {
. name = " __bitXor " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return the bitwise XOR of the integers * e1 * and * e2 * .
) " ,
. fun = prim_bitXor ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_lessThan ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2006-09-24 18:21:48 +03:00
{
2020-04-16 13:32:07 +03:00
state . forceValue ( * args [ 0 ] , pos ) ;
state . forceValue ( * args [ 1 ] , pos ) ;
2023-01-19 14:23:04 +02:00
// pos is exact here, no need for a message.
2022-11-29 01:25:36 +02:00
CompareValues comp ( state , noPos , " " ) ;
2022-01-04 19:40:39 +02:00
v . mkBool ( comp ( args [ 0 ] , args [ 1 ] ) ) ;
2006-09-24 18:21:48 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_lessThan ( {
. name = " __lessThan " ,
. args = { " e1 " , " e2 " } ,
. doc = R " (
Return ` true ` if the number * e1 * is less than the number * e2 * , and
` false ` otherwise . Evaluation aborts if either * e1 * or * e2 * does not
evaluate to a number .
) " ,
. fun = prim_lessThan ,
} ) ;
2006-09-24 18:21:48 +03:00
2007-01-29 16:23:09 +02:00
/*************************************************************
* String manipulation
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2007-01-29 17:15:37 +02:00
/* Convert the argument to a string. Paths are *not* copied to the
store , so ` toString / foo / bar ' yields ` " /foo/bar " ' , not
` " /nix/store/whatever... " ' . */
2022-03-04 20:31:59 +02:00
static void prim_toString ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 17:15:37 +02:00
{
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 ;
2022-11-29 01:25:36 +02:00
auto s = state . coerceToString ( pos , * args [ 0 ] , context ,
" while evaluating the first argument passed to builtins.toString " ,
true , false ) ;
2022-01-21 17:20:54 +02:00
v . mkString ( * s , context ) ;
2007-01-29 17:15:37 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_toString ( {
. name = " toString " ,
. args = { " e " } ,
. doc = R " (
Convert the expression * e * to a string . * e * can be :
- A string ( in which case the string is returned unmodified ) .
- A path ( e . g . , ` toString / foo / bar ` yields ` " /foo/bar " ` .
2021-07-09 23:50:10 +03:00
- A set containing ` { __toString = self : . . . ; } ` or ` { outPath = . . . ; } ` .
2020-08-24 15:31:10 +03:00
- An integer .
- A list , in which case the string representations of its elements
are joined with spaces .
- A Boolean ( ` false ` yields ` " " ` , ` true ` yields ` " 1 " ` ) .
- ` null ` , which yields the empty string .
) " ,
. fun = prim_toString ,
} ) ;
2007-01-29 17:15:37 +02:00
2007-12-31 02:08:09 +02:00
/* `substring start len str' returns the substring of `str' starting
at character position ` min ( start , stringLength str ) ' inclusive and
2007-01-29 16:23:09 +02:00
ending at ` min ( start + len , stringLength str ) ' . ` start ' must be
non - negative . */
2022-03-04 20:31:59 +02:00
static void prim_substring ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 16:23:09 +02:00
{
2023-01-19 14:23:04 +02:00
int start = state . forceInt ( * args [ 0 ] , pos , " while evaluating the first argument (the start offset) passed to builtins.substring " ) ;
2007-01-29 16:23:09 +02:00
2020-06-15 15:06:58 +03:00
if ( start < 0 )
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 < EvalError > ( " negative start position in 'substring' " ) . atPos ( pos ) . debugThrow ( ) ;
2007-01-29 16:23:09 +02:00
2024-01-12 00:40:54 +02:00
int len = state . forceInt ( * args [ 1 ] , pos , " while evaluating the second argument (the substring length) passed to builtins.substring " ) ;
// Special-case on empty substring to avoid O(n) strlen
// This allows for the use of empty substrings to efficently capture string context
if ( len = = 0 ) {
state . forceValue ( * args [ 2 ] , pos ) ;
if ( args [ 2 ] - > type ( ) = = nString ) {
v . mkString ( " " , args [ 2 ] - > context ( ) ) ;
return ;
}
}
NixStringContext context ;
auto s = state . coerceToString ( pos , * args [ 2 ] , context , " while evaluating the third argument (the string) passed to builtins.substring " ) ;
2022-01-21 17:20:54 +02:00
v . mkString ( ( unsigned int ) start > = s - > size ( ) ? " " : s - > substr ( start , len ) , context ) ;
2007-01-29 16:23:09 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_substring ( {
. name = " __substring " ,
. args = { " start " , " len " , " s " } ,
. doc = R " (
Return the substring of * s * from character position * start *
( zero - based ) up to but not including * start + len * . If * start * is
2023-10-24 12:22:02 +03:00
greater than the length of the string , an empty string is returned .
If * start + len * lies beyond the end of the string or * len * is ` - 1 ` ,
only the substring up to the end of the string is returned .
* start * must be non - negative .
For example ,
2020-08-24 15:31:10 +03:00
` ` ` nix
builtins . substring 0 3 " nixos "
` ` `
evaluates to ` " nix " ` .
) " ,
. fun = prim_substring ,
} ) ;
2007-01-29 16:23:09 +02:00
2022-03-04 20:31:59 +02:00
static void prim_stringLength ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2007-01-29 16:23:09 +02:00
{
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-01-19 14:23:04 +02:00
auto s = state . coerceToString ( pos , * args [ 0 ] , context , " while evaluating the argument passed to builtins.stringLength " ) ;
2022-01-21 17:20:54 +02:00
v . mkInt ( s - > size ( ) ) ;
2007-01-29 16:23:09 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_stringLength ( {
. name = " __stringLength " ,
. args = { " e " } ,
. doc = R " (
2024-03-28 01:46:50 +02:00
Return the number of bytes of the string * e * . If * e * is not a string ,
2020-08-24 15:31:10 +03:00
evaluation is aborted .
) " ,
. fun = prim_stringLength ,
} ) ;
2007-01-29 16:23:09 +02:00
2013-03-08 02:24:59 +02:00
/* Return the cryptographic hash of a string in base-16. */
2022-03-04 20:31:59 +02:00
static void prim_hashString ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2013-03-08 02:24:59 +02:00
{
2023-11-28 15:20:27 +02:00
auto algo = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.hashString " ) ;
std : : optional < HashAlgorithm > ha = parseHashAlgo ( algo ) ;
if ( ! ha )
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 < EvalError > ( " unknown hash algorithm '%1%' " , algo ) . atPos ( pos ) . debugThrow ( ) ;
2013-03-08 02:24:59 +02:00
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 ; // discarded
2023-01-19 14:23:04 +02:00
auto s = state . forceString ( * args [ 1 ] , context , pos , " while evaluating the second argument passed to builtins.hashString " ) ;
2013-03-08 02:24:59 +02:00
2023-11-28 15:20:27 +02:00
v . mkString ( hashString ( * ha , s ) . to_string ( HashFormat : : Base16 , false ) ) ;
2014-11-25 12:47:06 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_hashString ( {
. name = " __hashString " ,
. args = { " type " , " s " } ,
. doc = R " (
Return a base - 16 representation of the cryptographic hash of string
* s * . The hash algorithm specified by * type * must be one of ` " md5 " ` ,
` " sha1 " ` , ` " sha256 " ` or ` " sha512 " ` .
) " ,
. fun = prim_hashString ,
} ) ;
2014-11-25 12:47:06 +02:00
2023-01-29 08:03:06 +02:00
static void prim_convertHash ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
{
state . forceAttrs ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.convertHash " ) ;
2024-03-25 19:20:18 +02:00
auto inputAttrs = args [ 0 ] - > attrs ( ) ;
2023-01-29 08:03:06 +02:00
2024-03-25 19:20:18 +02:00
auto iteratorHash = getAttr ( state , state . symbols . create ( " hash " ) , inputAttrs , " while locating the attribute 'hash' " ) ;
2023-01-29 08:03:06 +02:00
auto hash = state . forceStringNoCtx ( * iteratorHash - > value , pos , " while evaluating the attribute 'hash' " ) ;
2024-03-25 19:20:18 +02:00
auto iteratorHashAlgo = inputAttrs - > get ( state . symbols . create ( " hashAlgo " ) ) ;
2023-11-28 15:20:27 +02:00
std : : optional < HashAlgorithm > ha = std : : nullopt ;
2024-03-25 19:20:18 +02:00
if ( iteratorHashAlgo )
2023-11-28 15:20:27 +02:00
ha = parseHashAlgo ( state . forceStringNoCtx ( * iteratorHashAlgo - > value , pos , " while evaluating the attribute 'hashAlgo' " ) ) ;
2023-01-29 08:03:06 +02:00
2024-03-25 19:20:18 +02:00
auto iteratorToHashFormat = getAttr ( state , state . symbols . create ( " toHashFormat " ) , args [ 0 ] - > attrs ( ) , " while locating the attribute 'toHashFormat' " ) ;
2023-01-29 08:03:06 +02:00
HashFormat hf = parseHashFormat ( state . forceStringNoCtx ( * iteratorToHashFormat - > value , pos , " while evaluating the attribute 'toHashFormat' " ) ) ;
2023-11-28 15:20:27 +02:00
v . mkString ( Hash : : parseAny ( hash , ha ) . to_string ( hf , hf = = HashFormat : : SRI ) ) ;
2023-01-29 08:03:06 +02:00
}
static RegisterPrimOp primop_convertHash ( {
. name = " __convertHash " ,
. args = { " args " } ,
. doc = R " (
Return the specified representation of a hash string , based on the attributes presented in * args * :
- ` hash `
The hash to be converted .
The hash format is detected automatically .
- ` hashAlgo `
The algorithm used to create the hash . Must be one of
- ` " md5 " `
- ` " sha1 " `
- ` " sha256 " `
- ` " sha512 " `
The attribute may be omitted when ` hash ` is an [ SRI hash ] ( https : //www.w3.org/TR/SRI/#the-integrity-attribute) or when the hash is prefixed with the hash algorithm name followed by a colon.
That ` < hashAlgo > : < hashBody > ` syntax is supported for backwards compatibility with existing tooling .
- ` toHashFormat `
The format of the resulting hash . Must be one of
- ` " base16 " `
2023-11-28 20:02:15 +02:00
- ` " nix32 " `
2023-12-02 12:53:50 +02:00
- ` " base32 " ` ( deprecated alias for ` " nix32 " ` )
2023-01-29 08:03:06 +02:00
- ` " base64 " `
- ` " sri " `
The result hash is the * toHashFormat * representation of the hash * hash * .
> * * Example * *
>
> Convert a SHA256 hash in Base16 to SRI :
>
> ` ` ` nix
> builtins . convertHash {
> hash = " e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 " ;
> toHashFormat = " sri " ;
> hashAlgo = " sha256 " ;
> }
> ` ` `
>
> " sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= "
> * * Example * *
>
> Convert a SHA256 hash in SRI to Base16 :
>
> ` ` ` nix
> builtins . convertHash {
> hash = " sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= " ;
> toHashFormat = " base16 " ;
> }
> ` ` `
>
> " e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 "
> * * Example * *
>
> Convert a hash in the form ` < hashAlgo > : < hashBody > ` in Base16 to SRI :
>
> ` ` ` nix
> builtins . convertHash {
> hash = " sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 " ;
> toHashFormat = " sri " ;
> }
> ` ` `
>
> " sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU= "
) " ,
. fun = prim_convertHash ,
} ) ;
2020-09-21 19:22:45 +03:00
struct RegexCache
{
2024-05-31 20:18:38 +03:00
struct State
{
// TODO use C++20 transparent comparison when available
std : : unordered_map < std : : string_view , std : : regex > cache ;
std : : list < std : : string > keys ;
} ;
Sync < State > state_ ;
2022-01-21 15:44:00 +02:00
2023-12-01 01:50:20 +02:00
std : : regex get ( std : : string_view re )
2022-01-21 15:44:00 +02:00
{
2024-05-31 20:18:38 +03:00
auto state ( state_ . lock ( ) ) ;
auto it = state - > cache . find ( re ) ;
if ( it ! = state - > cache . end ( ) )
2022-01-21 15:44:00 +02:00
return it - > second ;
2024-05-31 20:18:38 +03:00
state - > keys . emplace_back ( re ) ;
return state - > cache . emplace ( state - > keys . back ( ) , std : : regex ( state - > keys . back ( ) , std : : regex : : extended ) ) . first - > second ;
2022-01-21 15:44:00 +02:00
}
2020-09-21 19:22:45 +03:00
} ;
std : : shared_ptr < RegexCache > makeRegexCache ( )
{
return std : : make_shared < RegexCache > ( ) ;
}
2022-03-04 20:31:59 +02:00
void prim_match ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2014-11-25 12:47:06 +02:00
{
2023-01-19 14:23:04 +02:00
auto re = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.match " ) ;
2014-11-25 12:47:06 +02:00
2017-05-17 12:58:01 +03:00
try {
2016-10-18 21:21:21 +03:00
2022-01-21 15:44:00 +02:00
auto regex = state . regexCache - > get ( re ) ;
2014-11-25 12:47:06 +02:00
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-01-19 14:23:04 +02:00
const auto str = state . forceString ( * args [ 1 ] , context , pos , " while evaluating the second argument passed to builtins.match " ) ;
2014-11-25 12:47:06 +02:00
2023-12-01 01:50:20 +02:00
std : : cmatch match ;
if ( ! std : : regex_match ( str . begin ( ) , str . end ( ) , match , regex ) ) {
2022-01-04 19:40:39 +02:00
v . mkNull ( ) ;
2017-05-17 12:58:01 +03:00
return ;
}
// the first match is the whole string
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( match . size ( ) - 1 ) ;
for ( const auto & [ i , v2 ] : enumerate ( list ) )
if ( ! match [ i + 1 ] . matched )
2024-03-20 22:28:38 +02:00
v2 = & state . vNull ;
2017-05-17 12:58:01 +03:00
else
2024-03-14 20:10:31 +02:00
( v2 = state . allocValue ( ) ) - > mkString ( match [ i + 1 ] . str ( ) ) ;
v . mkList ( list ) ;
2017-05-17 12:58:01 +03:00
2023-12-01 01:50:20 +02:00
} catch ( std : : regex_error & e ) {
if ( e . code ( ) = = std : : regex_constants : : error_space ) {
2020-05-09 03:18:28 +03:00
// limit is _GLIBCXX_REGEX_STATE_LIMIT for libstdc++
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 < EvalError > ( " memory limit exceeded by regular expression '%s' " , re )
. atPos ( pos )
. debugThrow ( ) ;
2022-05-25 13:32:22 +03:00
} else
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 < EvalError > ( " invalid regular expression '%s' " , re )
. atPos ( pos )
. debugThrow ( ) ;
2014-11-25 12:47:06 +02:00
}
}
2013-03-08 02:24:59 +02:00
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_match ( {
. name = " __match " ,
. args = { " regex " , " str " } ,
. doc = R " s(
Returns a list if the [ extended POSIX regular
expression ] ( http : //pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04)
* regex * matches * str * precisely , otherwise returns ` null ` . Each item
in the list is a regex group .
` ` ` nix
builtins . match " ab " " abc "
` ` `
Evaluates to ` null ` .
` ` ` nix
builtins . match " abc " " abc "
` ` `
Evaluates to ` [ ] ` .
` ` ` nix
builtins . match " a(b)(c) " " abc "
` ` `
Evaluates to ` [ " b " " c " ] ` .
` ` ` nix
builtins . match " [[:space:]]+([[:upper:]]+)[[:space:]]+ " " FOO "
` ` `
2022-05-18 09:05:26 +03:00
Evaluates to ` [ " FOO " ] ` .
2020-08-24 15:31:10 +03:00
) s " ,
. fun = prim_match ,
} ) ;
2013-03-08 02:24:59 +02:00
2017-08-15 21:08:41 +03:00
/* Split a string with a regular expression, and return a list of the
non - matching parts interleaved by the lists of the matching groups . */
2022-03-04 20:31:59 +02:00
void prim_split ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2017-08-15 21:08:41 +03:00
{
2023-01-19 14:23:04 +02:00
auto re = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.split " ) ;
2017-08-15 21:08:41 +03:00
try {
2022-01-21 15:44:00 +02:00
auto regex = state . regexCache - > get ( re ) ;
2017-08-15 21:08:41 +03:00
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-01-19 14:23:04 +02:00
const auto str = state . forceString ( * args [ 1 ] , context , pos , " while evaluating the second argument passed to builtins.split " ) ;
2017-08-15 21:08:41 +03:00
2023-12-01 01:50:20 +02:00
auto begin = std : : cregex_iterator ( str . begin ( ) , str . end ( ) , regex ) ;
auto end = std : : cregex_iterator ( ) ;
2017-08-15 21:08:41 +03:00
// Any matches results are surrounded by non-matching results.
const size_t len = std : : distance ( begin , end ) ;
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( 2 * len + 1 ) ;
2017-08-15 21:08:41 +03:00
size_t idx = 0 ;
if ( len = = 0 ) {
2024-03-14 20:10:31 +02:00
list [ 0 ] = args [ 1 ] ;
v . mkList ( list ) ;
2017-08-15 21:08:41 +03:00
return ;
}
2022-01-21 15:44:00 +02:00
for ( auto i = begin ; i ! = end ; + + i ) {
2017-08-15 21:08:41 +03:00
assert ( idx < = 2 * len + 1 - 3 ) ;
2022-01-21 15:44:00 +02:00
auto match = * i ;
2017-08-15 21:08:41 +03:00
// Add a string for non-matched characters.
2024-03-14 20:10:31 +02:00
( list [ idx + + ] = state . allocValue ( ) ) - > mkString ( match . prefix ( ) . str ( ) ) ;
2017-08-15 21:08:41 +03:00
// Add a list for matched substrings.
const size_t slen = match . size ( ) - 1 ;
// Start at 1, beacause the first match is the whole string.
2024-03-14 20:10:31 +02:00
auto list2 = state . buildList ( slen ) ;
for ( const auto & [ si , v2 ] : enumerate ( list2 ) ) {
2017-08-15 21:08:41 +03:00
if ( ! match [ si + 1 ] . matched )
2024-03-14 20:10:31 +02:00
v2 = & state . vNull ;
2017-08-15 21:08:41 +03:00
else
2024-03-14 20:10:31 +02:00
( v2 = state . allocValue ( ) ) - > mkString ( match [ si + 1 ] . str ( ) ) ;
2017-08-15 21:08:41 +03:00
}
2024-03-14 20:10:31 +02:00
( list [ idx + + ] = state . allocValue ( ) ) - > mkList ( list2 ) ;
2017-08-15 21:08:41 +03:00
// Add a string for non-matched suffix characters.
2022-01-04 19:24:42 +02:00
if ( idx = = 2 * len )
2024-03-14 20:10:31 +02:00
( list [ idx + + ] = state . allocValue ( ) ) - > mkString ( match . suffix ( ) . str ( ) ) ;
2017-08-15 21:08:41 +03:00
}
2022-01-04 19:24:42 +02:00
2017-08-15 21:08:41 +03:00
assert ( idx = = 2 * len + 1 ) ;
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2023-12-01 01:50:20 +02:00
} catch ( std : : regex_error & e ) {
if ( e . code ( ) = = std : : regex_constants : : error_space ) {
2020-05-14 00:56:39 +03:00
// limit is _GLIBCXX_REGEX_STATE_LIMIT for libstdc++
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 < EvalError > ( " memory limit exceeded by regular expression '%s' " , re )
. atPos ( pos )
. debugThrow ( ) ;
2022-05-25 13:32:22 +03:00
} else
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 < EvalError > ( " invalid regular expression '%s' " , re )
. atPos ( pos )
. debugThrow ( ) ;
2017-08-15 21:08:41 +03:00
}
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_split ( {
. name = " __split " ,
. args = { " regex " , " str " } ,
. doc = R " s(
Returns a list composed of non matched strings interleaved with the
lists of the [ extended POSIX regular
expression ] ( http : //pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04)
* regex * matches of * str * . Each item in the lists of matched
sequences is a regex group .
` ` ` nix
builtins . split " (a)b " " abc "
` ` `
Evaluates to ` [ " " [ " a " ] " c " ] ` .
` ` ` nix
builtins . split " ([ac]) " " abc "
` ` `
2017-08-15 21:08:41 +03:00
2020-08-24 15:31:10 +03:00
Evaluates to ` [ " " [ " a " ] " b " [ " c " ] " " ] ` .
` ` ` nix
builtins . split " (a)|(c) " " abc "
` ` `
Evaluates to ` [ " " [ " a " null ] " b " [ null " c " ] " " ] ` .
2017-08-15 21:08:41 +03:00
2020-08-24 15:31:10 +03:00
` ` ` nix
2022-05-06 19:05:27 +03:00
builtins . split " ([[:upper:]]+) " " FOO "
2020-08-24 15:31:10 +03:00
` ` `
Evaluates to ` [ " " [ " FOO " ] " " ] ` .
) s " ,
. fun = prim_split ,
} ) ;
2022-03-04 20:31:59 +02:00
static void prim_concatStringsSep ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-24 03:31:58 +03:00
{
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 ;
2015-07-24 03:31:58 +03:00
2023-01-19 14:23:04 +02:00
auto sep = state . forceString ( * args [ 0 ] , context , pos , " while evaluating the first argument (the separator string) passed to builtins.concatStringsSep " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument (the list of strings to concat) passed to builtins.concatStringsSep " ) ;
2015-07-24 03:31:58 +03:00
2022-02-25 17:00:00 +02:00
std : : string res ;
2015-07-24 03:31:58 +03:00
res . reserve ( ( args [ 1 ] - > listSize ( ) + 32 ) * sep . size ( ) ) ;
bool first = true ;
2021-11-24 21:21:34 +02:00
for ( auto elem : args [ 1 ] - > listItems ( ) ) {
2015-07-24 03:31:58 +03:00
if ( first ) first = false ; else res + = sep ;
2023-01-19 14:23:04 +02:00
res + = * state . coerceToString ( pos , * elem , context , " while evaluating one element of the list of strings to concat passed to builtins.concatStringsSep " ) ;
2015-07-24 03:31:58 +03:00
}
2022-01-04 19:24:42 +02:00
v . mkString ( res , context ) ;
2015-07-24 03:31:58 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_concatStringsSep ( {
. name = " __concatStringsSep " ,
. args = { " separator " , " list " } ,
. doc = R " (
Concatenate a list of strings with a separator between each
element , e . g . ` concatStringsSep " / " [ " usr " " local " " bin " ] = =
" usr/local/bin " ` .
) " ,
. fun = prim_concatStringsSep ,
} ) ;
2015-07-24 03:31:58 +03:00
2022-03-04 20:31:59 +02:00
static void prim_replaceStrings ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2015-07-24 16:32:24 +03:00
{
2023-01-19 14:23:04 +02:00
state . forceList ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.replaceStrings " ) ;
state . forceList ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.replaceStrings " ) ;
2015-07-24 16:32:24 +03:00
if ( args [ 0 ] - > listSize ( ) ! = args [ 1 ] - > listSize ( ) )
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 < EvalError > (
" 'from' and 'to' arguments passed to builtins.replaceStrings have different lengths "
) . atPos ( pos ) . debugThrow ( ) ;
2015-07-24 16:32:24 +03:00
2022-02-25 17:00:00 +02:00
std : : vector < std : : string > from ;
2016-08-14 04:54:48 +03:00
from . reserve ( args [ 0 ] - > listSize ( ) ) ;
2021-11-24 21:21:34 +02:00
for ( auto elem : args [ 0 ] - > listItems ( ) )
2022-11-29 01:25:36 +02:00
from . emplace_back ( state . forceString ( * elem , pos , " while evaluating one of the strings to replace passed to builtins.replaceStrings " ) ) ;
2015-07-24 16:32:24 +03:00
2023-05-25 07:37:00 +03:00
std : : unordered_map < size_t , std : : string > cache ;
auto to = args [ 1 ] - > listItems ( ) ;
2015-07-24 16:32:24 +03:00
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-01-19 14:23:04 +02:00
auto s = state . forceString ( * args [ 2 ] , context , pos , " while evaluating the third argument passed to builtins.replaceStrings " ) ;
2015-07-24 16:32:24 +03:00
2022-02-25 17:00:00 +02:00
std : : string res ;
2018-02-19 17:52:33 +02:00
// Loops one past last character to handle the case where 'from' contains an empty string.
for ( size_t p = 0 ; p < = s . size ( ) ; ) {
2015-07-24 16:32:24 +03:00
bool found = false ;
2016-08-14 04:54:48 +03:00
auto i = from . begin ( ) ;
auto j = to . begin ( ) ;
2023-05-25 07:37:00 +03:00
size_t j_index = 0 ;
for ( ; i ! = from . end ( ) ; + + i , + + j , + + j_index )
2015-07-24 16:32:24 +03:00
if ( s . compare ( p , i - > size ( ) , * i ) = = 0 ) {
found = true ;
2023-05-25 07:37:00 +03:00
auto v = cache . find ( j_index ) ;
if ( v = = cache . end ( ) ) {
NixStringContext ctx ;
auto ts = state . forceString ( * * j , ctx , pos , " while evaluating one of the replacement strings passed to builtins.replaceStrings " ) ;
v = ( cache . emplace ( j_index , ts ) ) . first ;
for ( auto & path : ctx )
context . insert ( path ) ;
}
res + = v - > second ;
2018-02-19 17:52:33 +02:00
if ( i - > empty ( ) ) {
if ( p < s . size ( ) )
res + = s [ p ] ;
p + + ;
} else {
p + = i - > size ( ) ;
}
2015-07-24 16:32:24 +03:00
break ;
}
2018-02-19 17:52:33 +02:00
if ( ! found ) {
if ( p < s . size ( ) )
res + = s [ p ] ;
p + + ;
}
2015-07-24 16:32:24 +03:00
}
2022-01-04 19:24:42 +02:00
v . mkString ( res , context ) ;
2015-07-24 16:32:24 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_replaceStrings ( {
. name = " __replaceStrings " ,
. args = { " from " , " to " , " s " } ,
. doc = R " (
Given string * s * , replace every occurrence of the strings in * from *
2023-05-30 23:58:15 +03:00
with the corresponding string in * to * .
The argument * to * is lazy , that is , it is only evaluated when its corresponding pattern in * from * is matched in the string * s *
Example :
2020-08-24 15:31:10 +03:00
` ` ` nix
builtins . replaceStrings [ " oo " " a " ] [ " a " " i " ] " foobar "
` ` `
evaluates to ` " fabir " ` .
) " ,
. fun = prim_replaceStrings ,
} ) ;
2015-07-24 16:32:24 +03:00
2008-07-01 13:10:32 +03:00
/*************************************************************
* Versions
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2022-03-04 20:31:59 +02:00
static void prim_parseDrvName ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-07-01 13:10:32 +03:00
{
2023-01-19 14:23:04 +02:00
auto name = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.parseDrvName " ) ;
2008-07-01 13:10:32 +03:00
DrvName parsed ( name ) ;
2022-01-04 18:39:16 +02:00
auto attrs = state . buildBindings ( 2 ) ;
attrs . alloc ( state . sName ) . mkString ( parsed . name ) ;
attrs . alloc ( " version " ) . mkString ( parsed . version ) ;
v . mkAttrs ( attrs ) ;
2008-07-01 13:10:32 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_parseDrvName ( {
. name = " __parseDrvName " ,
. args = { " s " } ,
. doc = R " (
Split the string * s * into a package name and version . The package
2022-10-09 03:21:34 +03:00
name is everything up to but not including the first dash not followed
by a letter , and the version is everything following that dash . The
2020-08-24 15:31:10 +03:00
result is returned in a set ` { name , version } ` . Thus ,
` builtins . parseDrvName " nix-0.12pre12876 " ` returns ` { name =
" nix " ; version = " 0.12pre12876 " ; } ` .
) " ,
. fun = prim_parseDrvName ,
} ) ;
2008-07-01 13:10:32 +03:00
2022-03-04 20:31:59 +02:00
static void prim_compareVersions ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2008-07-01 13:10:32 +03:00
{
2023-01-19 14:23:04 +02:00
auto version1 = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.compareVersions " ) ;
auto version2 = state . forceStringNoCtx ( * args [ 1 ] , pos , " while evaluating the second argument passed to builtins.compareVersions " ) ;
2022-01-04 19:40:39 +02:00
v . mkInt ( compareVersions ( version1 , version2 ) ) ;
2008-07-01 13:10:32 +03:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_compareVersions ( {
. name = " __compareVersions " ,
. args = { " s1 " , " s2 " } ,
. doc = R " (
Compare two strings representing versions and return ` - 1 ` if
version * s1 * is older than version * s2 * , ` 0 ` if they are the same ,
and ` 1 ` if * s1 * is newer than * s2 * . The version comparison
algorithm is the same as the one used by [ ` nix - env
- u ` ] ( . . / command - ref / nix - env . md # operation - - - upgrade ) .
) " ,
. fun = prim_compareVersions ,
} ) ;
2008-07-01 13:10:32 +03:00
2022-03-04 20:31:59 +02:00
static void prim_splitVersion ( EvalState & state , const PosIdx pos , Value * * args , Value & v )
2018-02-14 01:28:27 +02:00
{
2023-01-19 14:23:04 +02:00
auto version = state . forceStringNoCtx ( * args [ 0 ] , pos , " while evaluating the first argument passed to builtins.splitVersion " ) ;
2018-02-14 01:28:27 +02:00
auto iter = version . cbegin ( ) ;
Strings components ;
while ( iter ! = version . cend ( ) ) {
auto component = nextComponent ( iter , version . cend ( ) ) ;
if ( component . empty ( ) )
break ;
2022-01-21 15:44:00 +02:00
components . emplace_back ( component ) ;
2018-02-14 01:28:27 +02:00
}
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( components . size ( ) ) ;
2022-01-04 19:24:42 +02:00
for ( const auto & [ n , component ] : enumerate ( components ) )
2024-03-14 20:10:31 +02:00
( list [ n ] = state . allocValue ( ) ) - > mkString ( std : : move ( component ) ) ;
v . mkList ( list ) ;
2018-02-14 01:28:27 +02:00
}
2020-08-24 15:31:10 +03:00
static RegisterPrimOp primop_splitVersion ( {
. name = " __splitVersion " ,
. args = { " s " } ,
. doc = R " (
Split a string representing a version into its components , by the
same version splitting logic underlying the version comparison in
[ ` nix - env - u ` ] ( . . / command - ref / nix - env . md # operation - - - upgrade ) .
) " ,
. fun = prim_splitVersion ,
} ) ;
2018-02-14 01:28:27 +02:00
2007-01-29 17:15:37 +02:00
/*************************************************************
* Primop registration
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */
2016-04-13 12:15:45 +03:00
RegisterPrimOp : : PrimOps * RegisterPrimOp : : primOps ;
2023-05-13 20:52:45 +03:00
RegisterPrimOp : : RegisterPrimOp ( PrimOp & & primOp )
2020-08-24 14:11:56 +03:00
{
if ( ! primOps ) primOps = new PrimOps ;
2023-05-13 20:52:45 +03:00
primOps - > push_back ( std : : move ( primOp ) ) ;
2016-04-13 12:15:45 +03:00
}
2010-03-29 17:37:56 +03:00
void EvalState : : createBaseEnv ( )
2004-08-04 13:59:20 +03:00
{
2010-03-29 17:37:56 +03:00
baseEnv . up = 0 ;
/* Add global constants such as `true' to the base environment. */
2010-03-30 17:39:27 +03:00
Value v ;
2010-04-15 01:59:39 +03:00
/* `builtins' must be first! */
2022-01-04 21:29:17 +02:00
v . mkAttrs ( buildBindings ( 128 ) . finish ( ) ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " builtins " , v , {
. type = nAttrs ,
. doc = R " (
2024-07-07 22:57:23 +03:00
Contains all the built - in functions and values .
2023-05-13 20:52:45 +03:00
Since built - in functions were added over time , [ testing for attributes ] ( . / operators . md # has - attribute ) in ` builtins ` can be used for graceful fallback on older Nix installations :
` ` ` nix
# if hasContext is not available, we assume `s` has a context
if builtins ? hasContext then builtins . hasContext s else true
` ` `
) " ,
} ) ;
2010-04-15 01:59:39 +03:00
2022-01-04 19:40:39 +02:00
v . mkBool ( true ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " true " , v , {
. type = nBool ,
. doc = R " (
Primitive value .
It can be returned by
[ comparison operators ] ( @ docroot @ / language / operators . md # Comparison )
and used in
2024-07-03 10:03:41 +03:00
[ conditional expressions ] ( @ docroot @ / language / syntax . md # Conditionals ) .
2023-05-13 20:52:45 +03:00
The name ` true ` is not special , and can be shadowed :
` ` ` nix - repl
nix - repl > let true = 1 ; in true
1
` ` `
) " ,
} ) ;
2013-09-02 17:29:15 +03:00
2022-01-04 19:40:39 +02:00
v . mkBool ( false ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " false " , v , {
. type = nBool ,
. doc = R " (
Primitive value .
It can be returned by
[ comparison operators ] ( @ docroot @ / language / operators . md # Comparison )
and used in
2024-07-03 10:03:41 +03:00
[ conditional expressions ] ( @ docroot @ / language / syntax . md # Conditionals ) .
2023-05-13 20:52:45 +03:00
The name ` false ` is not special , and can be shadowed :
` ` ` nix - repl
nix - repl > let false = 1 ; in false
1
` ` `
) " ,
} ) ;
2013-09-02 17:29:15 +03:00
2024-03-20 22:34:23 +02:00
addConstant ( " null " , & vNull , {
2023-05-13 20:52:45 +03:00
. type = nNull ,
. doc = R " (
Primitive value .
The name ` null ` is not special , and can be shadowed :
` ` ` nix - repl
nix - repl > let null = 1 ; in null
1
` ` `
) " ,
} ) ;
2010-03-30 17:39:27 +03:00
2024-06-14 19:41:09 +03:00
if ( ! settings . pureEval ) {
2022-01-04 19:40:39 +02:00
v . mkInt ( time ( 0 ) ) ;
2023-05-13 20:52:45 +03:00
}
addConstant ( " __currentTime " , v , {
. type = nInt ,
. doc = R " (
Return the [ Unix time ] ( https : //en.wikipedia.org/wiki/Unix_time) at first evaluation.
Repeated references to that name will re - use the initially obtained value .
Example :
` ` ` console
$ nix repl
Welcome to Nix 2.15 .1 Type : ? for help .
2018-01-16 19:50:38 +02:00
2023-05-13 20:52:45 +03:00
nix - repl > builtins . currentTime
1683705525
nix - repl > builtins . currentTime
1683705525
` ` `
2024-04-10 00:07:39 +03:00
The [ store path ] ( @ docroot @ / store / store - path . md ) of a derivation depending on ` currentTime ` will differ for each evaluation , unless both evaluate ` builtins . currentTime ` in the same second .
2023-05-13 20:52:45 +03:00
) " ,
. impureOnly = true ,
} ) ;
2024-06-14 19:41:09 +03:00
if ( ! settings . pureEval )
v . mkString ( settings . getCurrentSystem ( ) ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " __currentSystem " , v , {
. type = nString ,
. doc = R " (
2020-09-29 22:33:47 +03:00
The value of the
[ ` eval - system ` ] ( @ docroot @ / command - ref / conf - file . md # conf - eval - system )
or else
[ ` system ` ] ( @ docroot @ / command - ref / conf - file . md # conf - system )
configuration option .
2023-05-13 20:52:45 +03:00
It can be used to set the ` system ` attribute for [ ` builtins . derivation ` ] ( @ docroot @ / language / derivations . md ) such that the resulting derivation can be built on the same system that evaluates the Nix expression :
` ` ` nix
builtins . derivation {
# ...
system = builtins . currentSystem ;
}
` ` `
It can be overridden in order to create derivations for different system than the current one :
` ` ` console
$ nix - instantiate - - system " mips64-linux " - - eval - - expr ' builtins . currentSystem '
" mips64-linux "
` ` `
) " ,
. impureOnly = true ,
} ) ;
2004-08-04 13:59:20 +03:00
2022-01-04 19:24:42 +02:00
v . mkString ( nixVersion ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " __nixVersion " , v , {
. type = nString ,
. doc = R " (
The version of Nix .
For example , where the command line returns the current Nix version ,
` ` ` shell - session
$ nix - - version
nix ( Nix ) 2.16 .0
` ` `
the Nix language evaluator returns the same value :
` ` ` nix - repl
nix - repl > builtins . nixVersion
" 2.16.0 "
` ` `
) " ,
} ) ;
2012-11-27 14:29:55 +02:00
2022-01-04 19:24:42 +02:00
v . mkString ( store - > storeDir ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " __storeDir " , v , {
. type = nString ,
. doc = R " (
Logical file system location of the [ Nix store ] ( @ docroot @ / glossary . md # gloss - store ) currently in use .
2023-12-01 00:07:09 +02:00
This value is determined by the ` store ` parameter in [ Store URLs ] ( @ docroot @ / store / types / index . md # store - url - format ) :
2023-05-13 20:52:45 +03:00
` ` ` shell - session
$ nix - instantiate - - store ' dummy : //?store=/blah' --eval --expr builtins.storeDir
" /blah "
` ` `
) " ,
} ) ;
2015-03-24 12:15:45 +02:00
2012-11-27 14:29:55 +02:00
/* Language version. This should be increased every time a new
language feature gets added . It ' s not necessary to increase it
when primops get added , because you can just use ` builtins ?
primOp ' to check . */
2022-01-04 19:40:39 +02:00
v . mkInt ( 6 ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " __langVersion " , v , {
. type = nInt ,
. doc = R " (
The current version of the Nix language .
) " ,
} ) ;
2012-11-27 14:29:55 +02:00
2023-09-03 00:35:16 +03:00
# ifndef _WIN32 // TODO implement on Windows
2007-01-29 17:11:32 +02:00
// Miscellaneous
2024-06-14 19:41:09 +03:00
if ( settings . enableNativeCode ) {
2023-05-13 20:52:45 +03:00
addPrimOp ( {
. name = " __importNative " ,
. arity = 2 ,
. fun = prim_importNative ,
} ) ;
addPrimOp ( {
. name = " __exec " ,
. arity = 1 ,
. fun = prim_exec ,
} ) ;
2017-03-30 15:04:21 +03:00
}
2023-09-03 00:35:16 +03:00
# endif
2011-09-14 08:59:17 +03:00
2021-12-13 09:24:24 +02:00
addPrimOp ( {
2022-07-05 19:56:39 +03:00
. name = " __traceVerbose " ,
2021-12-13 09:24:24 +02:00
. args = { " e1 " , " e2 " } ,
2023-05-13 20:52:45 +03:00
. arity = 2 ,
2021-12-13 09:24:24 +02:00
. doc = R " (
Evaluate * e1 * and print its abstract syntax representation on standard
error if ` - - trace - verbose ` is enabled . Then return * e2 * . This function
is useful for debugging .
) " ,
2024-06-14 19:41:09 +03:00
. fun = settings . traceVerbose ? prim_trace : prim_second ,
2021-12-13 09:24:24 +02:00
} ) ;
2014-05-26 15:55:47 +03:00
/* Add a value containing the current Nix expression search path. */
2024-04-13 18:35:15 +03:00
auto list = buildList ( lookupPath . elements . size ( ) ) ;
for ( const auto & [ n , i ] : enumerate ( lookupPath . elements ) ) {
2022-01-04 18:39:16 +02:00
auto attrs = buildBindings ( 2 ) ;
2023-06-23 20:51:25 +03:00
attrs . alloc ( " path " ) . mkString ( i . path . s ) ;
attrs . alloc ( " prefix " ) . mkString ( i . prefix . s ) ;
2024-03-14 20:10:31 +02:00
( list [ n ] = allocValue ( ) ) - > mkAttrs ( attrs ) ;
2014-05-26 15:55:47 +03:00
}
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " __nixPath " , v , {
. type = nList ,
. doc = R " (
2024-03-09 19:57:57 +02:00
The value of the [ ` nix - path ` configuration setting ] ( @ docroot @ / command - ref / conf - file . md # conf - nix - path ) : a list of search path entries used to resolve [ lookup paths ] ( @ docroot @ / language / constructs / lookup - path . md ) .
2023-05-13 20:52:45 +03:00
2024-03-09 19:57:57 +02:00
Lookup path expressions are [ desugared ] ( https : //en.wikipedia.org/wiki/Syntactic_sugar) using this and
2023-05-13 20:52:45 +03:00
[ ` builtins . findFile ` ] ( . / builtins . html # builtins - findFile ) :
` ` ` nix
< nixpkgs >
` ` `
is equivalent to :
` ` ` nix
builtins . findFile builtins . nixPath " nixpkgs "
` ` `
) " ,
} ) ;
2014-05-26 15:55:47 +03:00
2016-04-13 12:15:45 +03:00
if ( RegisterPrimOp : : primOps )
for ( auto & primOp : * RegisterPrimOp : : primOps )
2023-05-13 20:52:45 +03:00
if ( experimentalFeatureSettings . isEnabled ( primOp . experimentalFeature ) )
2022-03-25 15:04:18 +02:00
{
2023-05-13 20:52:45 +03:00
auto primOpAdjusted = primOp ;
primOpAdjusted . arity = std : : max ( primOp . args . size ( ) , primOp . arity ) ;
addPrimOp ( std : : move ( primOpAdjusted ) ) ;
2022-03-25 15:04:18 +02:00
}
2016-04-13 12:15:45 +03:00
2020-08-24 15:31:10 +03:00
/* Add a wrapper around the derivation primop that computes the
2023-05-13 20:52:45 +03:00
` drvPath ' and ` outPath ' attributes lazily .
Null docs because it is documented separately .
*/
2020-03-02 19:15:06 +02:00
auto vDerivation = allocValue ( ) ;
2023-05-13 20:52:45 +03:00
addConstant ( " derivation " , vDerivation , {
. type = nFunction ,
} ) ;
2016-04-13 12:15:45 +03:00
2013-10-24 17:41:04 +03:00
/* Now that we've added all primops, sort the `builtins' set,
because attribute lookups expect it to be sorted . */
2024-03-25 19:20:18 +02:00
baseEnv . values [ 0 ] - > payload . attrs - > sort ( ) ;
2020-02-21 19:31:16 +02:00
2021-11-30 23:15:02 +02:00
staticBaseEnv - > sort ( ) ;
2020-03-02 19:15:06 +02:00
/* Note: we have to initialize the 'derivation' constant *after*
building baseEnv / staticBaseEnv because it uses ' builtins ' . */
2023-10-18 18:34:58 +03:00
evalFile ( derivationInternal , * vDerivation ) ;
2004-08-04 13:59:20 +03:00
}
2006-09-05 00:06:23 +03:00
2007-01-29 16:23:09 +02:00
2006-09-05 00:06:23 +03:00
}