2003-10-30 18:48:26 +02:00
# include "eval.hh"
2024-07-12 16:37:54 +03:00
# include "eval-gc.hh"
2023-07-31 16:19:19 +03:00
# include "eval-settings.hh"
2023-11-16 14:04:27 +02:00
# include "primops.hh"
2023-12-07 02:03:01 +02:00
# include "print-options.hh"
2024-06-27 05:26:45 +03:00
# include "exit.hh"
2022-01-21 17:20:54 +02:00
# include "types.hh"
2006-09-05 00:06:23 +03:00
# include "util.hh"
2006-11-30 19:43:04 +02:00
# include "store-api.hh"
2006-10-16 18:55:34 +03:00
# include "derivations.hh"
2023-05-12 01:01:41 +03:00
# include "downstream-placeholder.hh"
2012-02-04 15:50:25 +02:00
# include "eval-inline.hh"
2020-04-07 00:57:28 +03:00
# include "filetransfer.hh"
2019-11-13 18:38:37 +02:00
# include "function-trace.hh"
2023-03-21 14:37:19 +02:00
# include "profiles.hh"
2023-04-16 14:10:45 +03:00
# include "print.hh"
2024-05-06 18:29:03 +03:00
# include "filtering-source-accessor.hh"
2024-05-03 13:14:01 +03:00
# include "memory-source-accessor.hh"
2023-11-20 14:38:52 +02:00
# include "gc-small-vector.hh"
2023-12-06 16:27:29 +02:00
# include "url.hh"
2023-12-18 23:14:42 +02:00
# include "fetch-to-store.hh"
2024-01-15 17:52:18 +02:00
# include "tarball.hh"
2024-01-15 17:52:18 +02:00
# include "parser-tab.hh"
2004-02-04 18:03:29 +02:00
2014-03-30 01:49:23 +02:00
# include <algorithm>
2022-11-29 01:25:36 +02:00
# include <iostream>
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>
2010-03-29 17:37:56 +03:00
# include <cstring>
2022-11-29 01:25:36 +02:00
# include <optional>
2011-02-10 16:31:04 +02:00
# include <unistd.h>
2012-02-04 15:27:11 +02:00
# include <sys/time.h>
2018-09-02 01:50:22 +03:00
# include <fstream>
2021-12-23 00:38:49 +02:00
# include <functional>
2010-03-29 17:37:56 +03:00
2022-11-16 17:49:49 +02:00
# include <nlohmann/json.hpp>
2023-11-20 14:38:52 +02:00
# include <boost/container/small_vector.hpp>
2018-06-11 17:10:50 +03:00
2023-09-03 00:35:16 +03:00
# ifndef _WIN32 // TODO use portable implementation
2024-06-12 17:17:39 +03:00
# include <sys / resource.h>
2023-09-03 00:35:16 +03:00
# endif
2010-10-22 16:39:15 +03:00
# if HAVE_BOEHMGC
2024-06-12 17:17:39 +03:00
# define GC_INCLUDE_NEW
2020-04-16 17:28:07 +03:00
2024-06-12 17:17:39 +03:00
# include <gc / gc.h>
# include <gc / gc_cpp.h>
# include <gc / gc_allocator.h>
2020-10-30 21:55:53 +02:00
2010-10-22 16:39:15 +03:00
# endif
2024-07-14 13:19:55 +03:00
# include "strings-inline.hh"
2022-11-16 17:49:49 +02:00
using json = nlohmann : : json ;
2006-09-05 00:06:23 +03:00
namespace nix {
2010-10-24 03:41:29 +03:00
2021-12-27 03:04:49 +02:00
static char * allocString ( size_t size )
{
char * t ;
# if HAVE_BOEHMGC
t = ( char * ) GC_MALLOC_ATOMIC ( size ) ;
# else
2022-12-13 00:31:30 +02:00
t = ( char * ) malloc ( size ) ;
2021-12-27 03:04:49 +02:00
# endif
if ( ! t ) throw std : : bad_alloc ( ) ;
return t ;
}
2015-03-19 15:11:35 +02:00
static char * dupString ( const char * s )
{
char * t ;
# if HAVE_BOEHMGC
2018-06-12 17:16:03 +03:00
t = GC_STRDUP ( s ) ;
2015-03-19 15:11:35 +02:00
# else
t = strdup ( s ) ;
# endif
if ( ! t ) throw std : : bad_alloc ( ) ;
return t ;
}
2022-02-27 13:50:18 +02:00
// When there's no need to write to the string, we can optimize away empty
// string allocations.
2022-12-24 13:09:06 +02:00
// This function handles makeImmutableString(std::string_view()) by returning
// the empty string.
static const char * makeImmutableString ( std : : string_view s )
2019-12-05 20:11:09 +02:00
{
2022-12-24 13:09:06 +02:00
const size_t size = s . size ( ) ;
2022-02-27 13:50:18 +02:00
if ( size = = 0 )
return " " ;
2022-11-25 23:30:56 +02:00
auto t = allocString ( size + 1 ) ;
2022-12-24 13:09:06 +02:00
memcpy ( t , s . data ( ) , size ) ;
t [ size ] = ' \0 ' ;
2019-12-05 20:11:09 +02:00
return t ;
}
2020-04-16 17:28:07 +03:00
RootValue allocRootValue ( Value * v )
{
2021-06-26 01:57:37 +03:00
# if HAVE_BOEHMGC
2020-04-16 17:28:07 +03:00
return std : : allocate_shared < Value * > ( traceable_allocator < Value * > ( ) , v ) ;
2021-06-26 01:57:37 +03:00
# else
return std : : make_shared < Value * > ( v ) ;
# endif
2020-04-16 17:28:07 +03:00
}
2022-05-06 19:05:27 +03:00
// Pretty print types for assertion errors
std : : ostream & operator < < ( std : : ostream & os , const ValueType t ) {
os < < showType ( t ) ;
return os ;
}
2014-09-22 15:59:37 +03:00
2023-12-12 23:57:36 +02:00
std : : string printValue ( EvalState & state , Value & v )
2014-09-22 15:59:37 +03:00
{
2022-03-05 15:40:24 +02:00
std : : ostringstream out ;
2023-12-12 23:57:36 +02:00
v . print ( state , out ) ;
2022-03-05 15:40:24 +02:00
return out . str ( ) ;
2010-03-29 17:37:56 +03:00
}
2004-02-04 18:03:29 +02:00
2023-12-12 23:57:36 +02:00
void Value : : print ( EvalState & state , std : : ostream & str , PrintOptions options )
{
printValue ( state , str , * this , options ) ;
}
2004-10-27 01:54:26 +03:00
2022-02-25 17:00:00 +02:00
const Value * getPrimOp ( const Value & v ) {
2019-03-21 15:32:20 +02:00
const Value * primOp = & v ;
2020-12-12 03:15:11 +02:00
while ( primOp - > isPrimOpApp ( ) ) {
2024-03-25 19:20:18 +02:00
primOp = primOp - > payload . primOpApp . left ;
2019-03-21 15:32:20 +02:00
}
2020-12-12 03:15:11 +02:00
assert ( primOp - > isPrimOp ( ) ) ;
2019-03-21 15:32:20 +02:00
return primOp ;
}
2023-06-21 23:06:16 +03:00
std : : string_view showType ( ValueType type , bool withArticle )
2010-03-29 17:37:56 +03:00
{
2023-06-21 23:06:16 +03:00
# define WA(a, w) withArticle ? a " " w : w
2019-09-09 17:34:44 +03:00
switch ( type ) {
2023-06-21 23:06:16 +03:00
case nInt : return WA ( " an " , " integer " ) ;
case nBool : return WA ( " a " , " Boolean " ) ;
case nString : return WA ( " a " , " string " ) ;
case nPath : return WA ( " a " , " path " ) ;
2020-12-12 00:32:45 +02:00
case nNull : return " null " ;
2023-06-21 23:06:16 +03:00
case nAttrs : return WA ( " a " , " set " ) ;
case nList : return WA ( " a " , " list " ) ;
case nFunction : return WA ( " a " , " function " ) ;
case nExternal : return WA ( " an " , " external value " ) ;
case nFloat : return WA ( " a " , " float " ) ;
case nThunk : return WA ( " a " , " thunk " ) ;
2019-09-09 17:34:44 +03:00
}
2024-07-20 23:46:09 +03:00
unreachable ( ) ;
2019-09-09 17:34:44 +03:00
}
2022-02-25 17:00:00 +02:00
std : : string showType ( const Value & v )
2019-09-09 17:34:44 +03:00
{
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"
2020-12-17 15:42:52 +02:00
switch ( v . internalType ) {
2024-03-25 19:20:18 +02:00
case tString : return v . payload . string . context ? " a string with context " : " a string " ;
2019-03-21 15:32:20 +02:00
case tPrimOp :
2024-03-25 19:20:18 +02:00
return fmt ( " the built-in function '%s' " , std : : string ( v . payload . primOp - > name ) ) ;
2019-03-21 15:32:20 +02:00
case tPrimOpApp :
2024-03-25 19:20:18 +02:00
return fmt ( " the partially applied built-in function '%s' " , std : : string ( getPrimOp ( v ) - > payload . primOp - > name ) ) ;
case tExternal : return v . external ( ) - > showType ( ) ;
2023-12-11 17:23:08 +02:00
case tThunk : return v . isBlackhole ( ) ? " a black hole " : " a thunk " ;
2020-12-12 00:32:45 +02:00
case tApp : return " a function application " ;
2019-09-09 17:34:44 +03:00
default :
2022-02-25 17:00:00 +02:00
return std : : string ( showType ( v . type ( ) ) ) ;
2010-03-29 17:37:56 +03:00
}
2023-04-03 19:15:12 +03:00
# pragma GCC diagnostic pop
2010-03-29 17:37:56 +03:00
}
2022-03-04 20:31:59 +02:00
PosIdx Value : : determinePos ( const PosIdx pos ) const
2021-01-08 23:27:00 +02:00
{
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"
2021-01-08 23:27:00 +02:00
switch ( internalType ) {
2024-03-25 19:20:18 +02:00
case tAttrs : return attrs ( ) - > pos ;
case tLambda : return payload . lambda . fun - > pos ;
case tApp : return payload . app . left - > determinePos ( pos ) ;
2021-01-08 23:27:00 +02:00
default : return pos ;
}
2023-04-03 19:15:12 +03:00
# pragma GCC diagnostic pop
2021-01-08 23:27:00 +02:00
}
2009-05-12 14:06:24 +03:00
2019-09-09 18:34:38 +03:00
bool Value : : isTrivial ( ) const
{
return
2020-12-17 15:42:52 +02:00
internalType ! = tApp
& & internalType ! = tPrimOpApp
& & ( internalType ! = tThunk
2024-03-25 19:20:18 +02:00
| | ( dynamic_cast < ExprAttrs * > ( payload . thunk . expr )
& & ( ( ExprAttrs * ) payload . thunk . expr ) - > dynamicAttrs . empty ( ) )
| | dynamic_cast < ExprLambda * > ( payload . thunk . expr )
| | dynamic_cast < ExprList * > ( payload . thunk . expr ) ) ;
2019-09-09 18:34:38 +03:00
}
2014-04-04 22:14:11 +03:00
static Symbol getName ( const AttrName & name , EvalState & state , Env & env )
{
2022-03-05 15:40:24 +02:00
if ( name . symbol ) {
2014-01-01 01:56:26 +02:00
return name . symbol ;
} else {
Value nameValue ;
name . expr - > eval ( state , env , nameValue ) ;
2023-12-07 20:01:42 +02:00
state . forceStringNoCtx ( nameValue , name . expr - > getPos ( ) , " while evaluating an attribute name " ) ;
2023-09-26 04:30:41 +03:00
return state . symbols . create ( nameValue . string_view ( ) ) ;
2014-01-01 01:56:26 +02:00
}
}
2024-05-01 19:47:19 +03:00
static constexpr size_t BASE_ENV_SIZE = 128 ;
2021-06-29 22:09:48 +03:00
EvalState : : EvalState (
2024-07-25 00:17:15 +03:00
const LookupPath & lookupPathFromArguments ,
2021-06-29 22:09:48 +03:00
ref < Store > store ,
2024-07-01 20:37:30 +03:00
const fetchers : : Settings & fetchSettings ,
2024-06-14 19:41:09 +03:00
const EvalSettings & settings ,
2021-06-29 22:09:48 +03:00
std : : shared_ptr < Store > buildStore )
2024-07-01 20:37:30 +03:00
: fetchSettings { fetchSettings }
, settings { settings }
2024-06-14 19:41:09 +03:00
, sWith ( symbols . create ( " <with> " ) )
2010-04-13 15:25:42 +03:00
, sOutPath ( symbols . create ( " outPath " ) )
, sDrvPath ( symbols . create ( " drvPath " ) )
, sType ( symbols . create ( " type " ) )
, sMeta ( symbols . create ( " meta " ) )
, sName ( symbols . create ( " name " ) )
2013-10-28 08:34:44 +02:00
, sValue ( symbols . create ( " value " ) )
2010-04-21 18:08:58 +03:00
, sSystem ( symbols . create ( " system " ) )
2010-05-15 11:10:12 +03:00
, sOverrides ( symbols . create ( " __overrides " ) )
2012-11-28 14:49:44 +02:00
, sOutputs ( symbols . create ( " outputs " ) )
2012-11-26 18:39:09 +02:00
, sOutputName ( symbols . create ( " outputName " ) )
2012-11-27 16:01:32 +02:00
, sIgnoreNulls ( symbols . create ( " __ignoreNulls " ) )
2013-11-18 21:14:54 +02:00
, sFile ( symbols . create ( " file " ) )
, sLine ( symbols . create ( " line " ) )
, sColumn ( symbols . create ( " column " ) )
2014-10-16 05:04:48 +03:00
, sFunctor ( symbols . create ( " __functor " ) )
2015-11-27 21:20:29 +02:00
, sToString ( symbols . create ( " __toString " ) )
2016-08-29 18:28:20 +03:00
, sRight ( symbols . create ( " right " ) )
, sWrong ( symbols . create ( " wrong " ) )
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
, sStructuredAttrs ( symbols . create ( " __structuredAttrs " ) )
2024-06-10 16:31:21 +03:00
, sAllowedReferences ( symbols . create ( " allowedReferences " ) )
, sAllowedRequisites ( symbols . create ( " allowedRequisites " ) )
, sDisallowedReferences ( symbols . create ( " disallowedReferences " ) )
, sDisallowedRequisites ( symbols . create ( " disallowedRequisites " ) )
, sMaxSize ( symbols . create ( " maxSize " ) )
, sMaxClosureSize ( symbols . create ( " maxClosureSize " ) )
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
, sBuilder ( symbols . create ( " builder " ) )
2017-03-04 15:24:06 +02:00
, sArgs ( symbols . create ( " args " ) )
2020-07-23 02:59:25 +03:00
, sContentAddressed ( symbols . create ( " __contentAddressed " ) )
2022-03-30 17:31:01 +03:00
, sImpure ( symbols . create ( " __impure " ) )
2017-03-04 15:24:06 +02:00
, sOutputHash ( symbols . create ( " outputHash " ) )
, sOutputHashAlgo ( symbols . create ( " outputHashAlgo " ) )
, sOutputHashMode ( symbols . create ( " outputHashMode " ) )
2020-06-18 14:44:40 +03:00
, sRecurseForDerivations ( symbols . create ( " recurseForDerivations " ) )
2018-11-29 20:18:36 +02:00
, sDescription ( symbols . create ( " description " ) )
2019-08-30 12:22:34 +03:00
, sSelf ( symbols . create ( " self " ) )
2020-04-18 00:04:21 +03:00
, sEpsilon ( symbols . create ( " " ) )
2022-01-12 19:08:48 +02:00
, sStartSet ( symbols . create ( " startSet " ) )
, sOperator ( symbols . create ( " operator " ) )
, sKey ( symbols . create ( " key " ) )
, sPath ( symbols . create ( " path " ) )
, sPrefix ( symbols . create ( " prefix " ) )
2022-05-30 12:32:37 +03:00
, sOutputSpecified ( symbols . create ( " outputSpecified " ) )
2024-01-15 17:52:18 +02:00
, exprSymbols {
. sub = symbols . create ( " __sub " ) ,
. lessThan = symbols . create ( " __lessThan " ) ,
. mul = symbols . create ( " __mul " ) ,
. div = symbols . create ( " __div " ) ,
. or_ = symbols . create ( " or " ) ,
. findFile = symbols . create ( " __findFile " ) ,
. nixPath = symbols . create ( " __nixPath " ) ,
2024-01-22 16:15:53 +02:00
. body = symbols . create ( " body " ) ,
2024-01-15 17:52:18 +02:00
}
2017-06-28 19:11:01 +03:00
, repair ( NoRepair )
2022-01-04 20:23:11 +02:00
, emptyBindings ( 0 )
2023-11-30 17:16:17 +02:00
, rootFS (
2024-06-14 19:41:09 +03:00
settings . restrictEval | | settings . pureEval
2024-05-06 20:16:52 +03:00
? ref < SourceAccessor > ( AllowListSourceAccessor : : create ( getFSSourceAccessor ( ) , { } ,
2024-06-14 19:41:09 +03:00
[ & settings ] ( const CanonPath & path ) - > RestrictedPathError {
auto modeInformation = settings . pureEval
2023-11-30 17:16:17 +02:00
? " in pure evaluation mode (use '--impure' to override) "
: " in restricted mode " ;
throw RestrictedPathError ( " access to absolute path '%1%' is forbidden %2% " , path , modeInformation ) ;
} ) )
2024-05-06 20:16:52 +03:00
: getFSSourceAccessor ( ) )
2024-05-03 13:14:01 +03:00
, corepkgsFS ( make_ref < MemorySourceAccessor > ( ) )
, internalFS ( make_ref < MemorySourceAccessor > ( ) )
2023-10-18 18:34:58 +03:00
, derivationInternal { corepkgsFS - > addFile (
CanonPath ( " derivation-internal.nix " ) ,
# include "primops/derivation.nix.gen.hh"
) }
, callFlakeInternal { internalFS - > addFile (
CanonPath ( " call-flake.nix " ) ,
2024-06-28 02:19:32 +03:00
# include "call-flake.nix.gen.hh"
2023-10-18 18:34:58 +03:00
) }
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
, store ( store )
2021-06-29 22:09:48 +03:00
, buildStore ( buildStore ? buildStore : store )
2022-06-02 21:17:28 +03:00
, debugRepl ( nullptr )
2022-02-11 23:14:25 +02:00
, debugStop ( false )
2022-06-02 21:17:28 +03:00
, trylevel ( 0 )
2020-09-21 19:22:45 +03:00
, regexCache ( makeRegexCache ( ) )
2022-01-22 22:17:35 +02:00
# if HAVE_BOEHMGC
, valueAllocCache ( std : : allocate_shared < void * > ( traceable_allocator < void * > ( ) , nullptr ) )
2021-12-26 20:32:08 +02:00
, env1AllocCache ( std : : allocate_shared < void * > ( traceable_allocator < void * > ( ) , nullptr ) )
2024-05-01 19:47:19 +03:00
, baseEnvP ( std : : allocate_shared < Env * > ( traceable_allocator < Env * > ( ) , & allocEnv ( BASE_ENV_SIZE ) ) )
, baseEnv ( * * baseEnvP )
# else
, baseEnv ( allocEnv ( BASE_ENV_SIZE ) )
2022-01-22 22:17:35 +02:00
# endif
2023-12-22 19:19:53 +02:00
, staticBaseEnv { std : : make_shared < StaticEnv > ( nullptr , nullptr ) }
2010-03-29 17:37:56 +03:00
{
2023-11-20 19:54:36 +02:00
corepkgsFS - > setPathDisplay ( " <nix " , " > " ) ;
internalFS - > setPathDisplay ( " «nix-internal» " , " " ) ;
2019-11-22 17:06:44 +02:00
countCalls = getEnv ( " NIX_COUNT_CALLS " ) . value_or ( " 0 " ) ! = " 0 " ;
2010-03-29 17:37:56 +03:00
2024-06-12 17:17:39 +03:00
assertGCInitialized ( ) ;
2011-08-06 19:05:24 +03:00
2021-10-22 23:27:04 +03:00
static_assert ( sizeof ( Env ) < = 16 , " environment must be <= 16 bytes " ) ;
2018-05-22 17:02:32 +03:00
2024-03-14 20:10:31 +02:00
vEmptyList . mkList ( buildList ( 0 ) ) ;
vNull . mkNull ( ) ;
2024-03-21 00:06:23 +02:00
vTrue . mkBool ( true ) ;
vFalse . mkBool ( false ) ;
2024-03-20 23:56:42 +02:00
vStringRegular . mkString ( " regular " ) ;
vStringDirectory . mkString ( " directory " ) ;
vStringSymlink . mkString ( " symlink " ) ;
vStringUnknown . mkString ( " unknown " ) ;
Optimize empty list constants
This avoids a Value allocation for empty list constants. During a `nix
search nixpkgs`, about 82% of all thunked lists are empty, so this
removes about 3 million Value allocations.
Performance comparison on `nix search github:NixOS/nixpkgs/e1fa12d4f6c6fe19ccb59cac54b5b3f25e160870 --no-eval-cache`:
maximum RSS: median = 3845432.0000 mean = 3845432.0000 stddev = 0.0000 min = 3845432.0000 max = 3845432.0000 [rejected?, p=0.00000, Δ=-70084.00000±0.00000]
soft page faults: median = 965395.0000 mean = 965394.6667 stddev = 1.1181 min = 965392.0000 max = 965396.0000 [rejected?, p=0.00000, Δ=-17929.77778±38.59610]
system CPU time: median = 1.8029 mean = 1.7702 stddev = 0.0621 min = 1.6749 max = 1.8417 [rejected, p=0.00064, Δ=-0.12873±0.09905]
user CPU time: median = 14.1022 mean = 14.0633 stddev = 0.1869 min = 13.8118 max = 14.3190 [not rejected, p=0.03006, Δ=-0.18248±0.24928]
elapsed time: median = 15.8205 mean = 15.8618 stddev = 0.2312 min = 15.5033 max = 16.1670 [not rejected, p=0.00558, Δ=-0.28963±0.29434]
2024-01-02 13:39:16 +02:00
2024-07-25 00:17:15 +03:00
/* Construct the Nix expression search path. */
assert ( lookupPath . elements . empty ( ) ) ;
2024-06-14 19:41:09 +03:00
if ( ! settings . pureEval ) {
2024-07-25 00:17:15 +03:00
for ( auto & i : lookupPathFromArguments . elements ) {
2024-04-13 18:35:15 +03:00
lookupPath . elements . emplace_back ( LookupPath : : Elem { i } ) ;
2024-07-25 00:17:15 +03:00
}
/* $NIX_PATH overriding regular settings is implemented as a hack in `initGC()` */
for ( auto & i : settings . nixPath . get ( ) ) {
2024-04-13 18:35:15 +03:00
lookupPath . elements . emplace_back ( LookupPath : : Elem : : parse ( i ) ) ;
2024-07-25 00:17:15 +03:00
}
if ( ! settings . restrictEval ) {
for ( auto & i : EvalSettings : : getDefaultNixPath ( ) ) {
lookupPath . elements . emplace_back ( LookupPath : : Elem : : parse ( i ) ) ;
}
}
2018-01-16 19:50:38 +02:00
}
2012-01-03 16:01:47 +02:00
2023-11-30 17:16:17 +02:00
/* Allow access to all paths in the search path. */
2024-05-06 18:29:03 +03:00
if ( rootFS . dynamic_pointer_cast < AllowListSourceAccessor > ( ) )
2024-04-13 18:35:15 +03:00
for ( auto & i : lookupPath . elements )
resolveLookupPathPath ( i . path , true ) ;
2018-01-16 19:50:38 +02:00
2023-10-18 18:34:58 +03:00
corepkgsFS - > addFile (
CanonPath ( " fetchurl.nix " ) ,
# include "fetchurl.nix.gen.hh"
) ;
2012-01-03 16:01:47 +02:00
createBaseEnv ( ) ;
2004-02-04 18:03:29 +02:00
}
2010-04-09 15:00:49 +03:00
EvalState : : ~ EvalState ( )
{
}
2021-10-07 13:11:00 +03:00
void EvalState : : allowPath ( const Path & path )
{
2024-05-06 18:29:03 +03:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListSourceAccessor > ( ) )
2024-02-20 12:21:28 +02:00
rootFS2 - > allowPrefix ( CanonPath ( path ) ) ;
2021-10-07 13:11:00 +03:00
}
2021-10-07 15:07:51 +03:00
void EvalState : : allowPath ( const StorePath & storePath )
{
2024-05-06 18:29:03 +03:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListSourceAccessor > ( ) )
2024-02-20 12:21:28 +02:00
rootFS2 - > allowPrefix ( CanonPath ( store - > toRealPath ( storePath ) ) ) ;
2021-10-07 15:07:51 +03:00
}
2022-05-05 13:29:14 +03:00
void EvalState : : allowAndSetStorePathString ( const StorePath & storePath , Value & v )
2022-02-27 16:59:34 +02:00
{
allowPath ( 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
mkStorePathString ( storePath , v ) ;
2022-02-27 16:59:34 +02:00
}
2023-12-06 16:27:29 +02:00
inline static bool isJustSchemePrefix ( std : : string_view prefix )
{
return
! prefix . empty ( )
& & prefix [ prefix . size ( ) - 1 ] = = ' : '
& & isValidSchemeName ( prefix . substr ( 0 , prefix . size ( ) - 1 ) ) ;
}
2023-12-06 13:41:47 +02:00
bool isAllowedURI ( std : : string_view uri , const Strings & allowedUris )
2017-10-30 13:39:59 +02:00
{
/* 'uri' should be equal to a prefix, or in a subdirectory of a
prefix . Thus , the prefix https : //github.co does not permit
2023-12-06 13:43:20 +02:00
access to https : //github.com. */
2023-12-06 13:41:47 +02:00
for ( auto & prefix : allowedUris ) {
2023-12-06 15:08:22 +02:00
if ( uri = = prefix
// Allow access to subdirectories of the prefix.
| | ( uri . size ( ) > prefix . size ( )
& & prefix . size ( ) > 0
& & hasPrefix ( uri , prefix )
& & (
2023-12-06 16:27:29 +02:00
// Allow access to subdirectories of the prefix.
2023-12-06 15:08:22 +02:00
prefix [ prefix . size ( ) - 1 ] = = ' / '
2023-12-06 16:27:29 +02:00
| | uri [ prefix . size ( ) ] = = ' / '
// Allow access to whole schemes
| | isJustSchemePrefix ( prefix )
)
) )
2023-12-06 13:41:47 +02:00
return true ;
}
return false ;
}
void EvalState : : checkURI ( const std : : string & uri )
{
2024-06-14 19:41:09 +03:00
if ( ! settings . restrictEval ) return ;
2023-12-06 13:41:47 +02:00
2024-06-14 19:41:09 +03:00
if ( isAllowedURI ( uri , settings . allowedUris . get ( ) ) ) return ;
2017-10-30 13:39:59 +02:00
2018-02-06 15:35:14 +02:00
/* If the URI is a path, then check it against allowedPaths as
well . */
if ( hasPrefix ( uri , " / " ) ) {
2024-05-06 18:29:03 +03:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListSourceAccessor > ( ) )
2023-11-30 22:54:53 +02:00
rootFS2 - > checkAccess ( CanonPath ( uri ) ) ;
2018-02-06 15:35:14 +02:00
return ;
}
if ( hasPrefix ( uri , " file:// " ) ) {
2024-05-06 18:29:03 +03:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListSourceAccessor > ( ) )
2023-11-30 22:54:53 +02:00
rootFS2 - > checkAccess ( CanonPath ( uri . substr ( 7 ) ) ) ;
2018-02-06 15:35:14 +02:00
return ;
}
2017-10-30 13:39:59 +02:00
throw RestrictedPathError ( " access to URI '%s' is forbidden in restricted mode " , uri ) ;
}
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
Path EvalState : : toRealPath ( const Path & path , const NixStringContext & context )
2018-01-12 18:31:08 +02:00
{
// FIXME: check whether 'path' is in 'context'.
return
! context . empty ( ) & & store - > isInStore ( path )
? store - > toRealPath ( path )
: path ;
2019-11-10 18:23:35 +02:00
}
2018-01-12 18:31:08 +02:00
2023-05-13 20:52:45 +03:00
Value * EvalState : : addConstant ( const std : : string & name , Value & v , Constant info )
2010-03-30 17:39:27 +03:00
{
2010-10-22 17:47:42 +03:00
Value * v2 = allocValue ( ) ;
* v2 = v ;
2023-05-13 20:52:45 +03:00
addConstant ( name , v2 , info ) ;
2018-02-08 20:00:53 +02:00
return v2 ;
2010-03-30 17:39:27 +03:00
}
2023-05-13 20:52:45 +03:00
void EvalState : : addConstant ( const std : : string & name , Value * v , Constant info )
2020-03-02 19:15:06 +02:00
{
2022-02-25 17:00:00 +02:00
auto name2 = name . substr ( 0 , 2 ) = = " __ " ? name . substr ( 2 ) : name ;
2010-03-30 17:39:27 +03:00
2023-05-13 20:52:45 +03:00
constantInfos . push_back ( { name2 , info } ) ;
2010-03-30 17:39:27 +03:00
2024-06-14 19:41:09 +03:00
if ( ! ( settings . pureEval & & info . impureOnly ) ) {
2023-05-13 20:52:45 +03:00
/* Check the type, if possible.
We might know the type of a thunk in advance , so be allowed
to just write it down in that case . */
if ( auto gotType = v - > type ( true ) ; gotType ! = nThunk )
assert ( info . type = = gotType ) ;
/* Install value the base environment. */
staticBaseEnv - > vars . emplace_back ( symbols . create ( name ) , baseEnvDispl ) ;
baseEnv . values [ baseEnvDispl + + ] = v ;
2024-03-25 19:20:18 +02:00
baseEnv . values [ 0 ] - > payload . attrs - > push_back ( Attr ( symbols . create ( name2 ) , v ) ) ;
2023-05-13 20:52:45 +03:00
}
2003-10-31 19:09:31 +02:00
}
2023-11-16 12:10:25 +02:00
void PrimOp : : check ( )
{
if ( arity > maxPrimOpArity ) {
throw Error ( " primop arity must not exceed %1% " , maxPrimOpArity ) ;
}
}
2024-03-25 19:20:18 +02:00
std : : ostream & operator < < ( std : : ostream & output , const PrimOp & primOp )
2023-12-12 23:57:36 +02:00
{
output < < " primop " < < primOp . name ;
return output ;
}
2024-03-25 19:20:18 +02:00
const PrimOp * Value : : primOpAppPrimOp ( ) const
2023-12-12 23:57:36 +02:00
{
2024-03-25 19:20:18 +02:00
Value * left = payload . primOpApp . left ;
2023-12-12 23:57:36 +02:00
while ( left & & ! left - > isPrimOp ( ) ) {
2024-03-25 19:20:18 +02:00
left = left - > payload . primOpApp . left ;
2023-12-12 23:57:36 +02:00
}
if ( ! left )
return nullptr ;
2024-03-25 19:20:18 +02:00
return left - > primOp ( ) ;
2023-12-12 23:57:36 +02:00
}
2023-11-16 12:10:25 +02:00
void Value : : mkPrimOp ( PrimOp * p )
{
p - > check ( ) ;
2024-03-25 19:20:18 +02:00
finishValue ( tPrimOp , { . primOp = p } ) ;
2023-11-16 12:10:25 +02:00
}
2020-08-24 14:11:56 +03:00
Value * EvalState : : addPrimOp ( PrimOp & & primOp )
{
/* Hack to make constants lazy: turn them into a application of
the primop to a dummy value . */
if ( primOp . arity = = 0 ) {
primOp . arity = 1 ;
auto vPrimOp = allocValue ( ) ;
2022-03-05 20:26:36 +02:00
vPrimOp - > mkPrimOp ( new PrimOp ( primOp ) ) ;
2020-08-24 14:11:56 +03:00
Value v ;
2022-01-04 19:40:39 +02:00
v . mkApp ( vPrimOp , vPrimOp ) ;
2023-05-13 20:52:45 +03:00
return addConstant ( primOp . name , v , {
. type = nThunk , // FIXME
. doc = primOp . doc ,
} ) ;
2020-08-24 14:11:56 +03:00
}
2022-03-05 15:40:24 +02:00
auto envName = symbols . create ( primOp . name ) ;
2020-08-24 14:11:56 +03:00
if ( hasPrefix ( primOp . name , " __ " ) )
2022-03-05 20:26:36 +02:00
primOp . name = primOp . name . substr ( 2 ) ;
2020-08-24 14:11:56 +03:00
Value * v = allocValue ( ) ;
2022-03-05 20:26:36 +02:00
v - > mkPrimOp ( new PrimOp ( primOp ) ) ;
2021-11-25 17:53:59 +02:00
staticBaseEnv - > vars . emplace_back ( envName , baseEnvDispl ) ;
2020-08-24 14:11:56 +03:00
baseEnv . values [ baseEnvDispl + + ] = v ;
2024-03-25 19:20:18 +02:00
baseEnv . values [ 0 ] - > payload . attrs - > push_back ( Attr ( symbols . create ( primOp . name ) , v ) ) ;
2020-08-24 14:11:56 +03:00
return v ;
}
2022-02-25 17:00:00 +02:00
Value & EvalState : : getBuiltin ( const std : : string & name )
2013-09-03 16:45:32 +03:00
{
2024-03-25 19:20:18 +02:00
return * baseEnv . values [ 0 ] - > attrs ( ) - > find ( symbols . create ( name ) ) - > value ;
2013-09-03 16:45:32 +03:00
}
2020-08-25 14:31:11 +03:00
std : : optional < EvalState : : Doc > EvalState : : getDoc ( Value & v )
{
2021-03-03 18:52:57 +02:00
if ( v . isPrimOp ( ) ) {
2020-08-25 14:31:11 +03:00
auto v2 = & v ;
2024-03-25 19:20:18 +02:00
if ( auto * doc = v2 - > primOp ( ) - > doc )
2020-08-25 14:31:11 +03:00
return Doc {
2022-03-04 20:31:59 +02:00
. pos = { } ,
2024-03-25 19:20:18 +02:00
. name = v2 - > primOp ( ) - > name ,
. arity = v2 - > primOp ( ) - > arity ,
. args = v2 - > primOp ( ) - > args ,
2023-05-13 20:52:45 +03:00
. doc = doc ,
2020-08-25 14:31:11 +03:00
} ;
}
2024-07-08 18:39:26 +03:00
if ( v . isLambda ( ) ) {
auto exprLambda = v . payload . lambda . fun ;
std : : stringstream s ( std : : ios_base : : out ) ;
std : : string name ;
auto pos = positions [ exprLambda - > getPos ( ) ] ;
std : : string docStr ;
if ( exprLambda - > name ) {
name = symbols [ exprLambda - > name ] ;
}
if ( exprLambda - > docComment ) {
2024-07-09 20:26:22 +03:00
docStr = exprLambda - > docComment . getInnerText ( positions ) ;
2024-07-08 18:39:26 +03:00
}
if ( name . empty ( ) ) {
2024-07-15 20:55:05 +03:00
s < < " Function " ;
2024-07-08 18:39:26 +03:00
}
else {
2024-07-15 20:55:05 +03:00
s < < " Function ` " < < name < < " ` " ;
2024-07-08 18:39:26 +03:00
if ( pos )
s < < " \\ \n … " ;
else
s < < " \\ \n " ;
}
if ( pos ) {
2024-07-15 20:55:05 +03:00
s < < " defined at " < < pos ;
2024-07-08 18:39:26 +03:00
}
if ( ! docStr . empty ( ) ) {
s < < " \n \n " ;
}
s < < docStr ;
s < < ' \0 ' ; // for making a c string below
std : : string ss = s . str ( ) ;
return Doc {
. pos = pos ,
. name = name ,
. arity = 0 , // FIXME: figure out how deep by syntax only? It's not semantically useful though...
. args = { } ,
. doc =
// FIXME: this leaks; make the field std::string?
strdup ( ss . data ( ) ) ,
} ;
}
2020-08-25 14:31:11 +03:00
return { } ;
}
2022-03-31 18:37:36 +03:00
// just for the current level of StaticEnv, not the whole chain.
2022-05-05 13:29:14 +03:00
void printStaticEnvBindings ( const SymbolTable & st , const StaticEnv & se )
2021-10-02 22:47:36 +03:00
{
2022-03-31 18:37:36 +03:00
std : : cout < < ANSI_MAGENTA ;
2022-05-05 13:29:14 +03:00
for ( auto & i : se . vars )
std : : cout < < st [ i . first ] < < " " ;
2022-03-31 18:37:36 +03:00
std : : cout < < ANSI_NORMAL ;
std : : cout < < std : : endl ;
}
2022-01-05 21:28:31 +02:00
2022-03-31 18:37:36 +03:00
// just for the current level of Env, not the whole chain.
2022-05-05 13:29:14 +03:00
void printWithBindings ( const SymbolTable & st , const Env & env )
2022-03-31 18:37:36 +03:00
{
2023-12-22 19:19:53 +02:00
if ( ! env . values [ 0 ] - > isThunk ( ) ) {
2022-04-29 20:24:54 +03:00
std : : cout < < " with: " ;
2022-01-05 21:28:31 +02:00
std : : cout < < ANSI_MAGENTA ;
2024-03-25 19:20:18 +02:00
auto j = env . values [ 0 ] - > attrs ( ) - > begin ( ) ;
while ( j ! = env . values [ 0 ] - > attrs ( ) - > end ( ) ) {
2022-04-29 19:02:17 +03:00
std : : cout < < st [ j - > name ] < < " " ;
2022-03-31 18:37:36 +03:00
+ + j ;
2022-01-04 03:29:43 +02:00
}
2022-01-05 21:28:31 +02:00
std : : cout < < ANSI_NORMAL ;
2022-01-04 03:29:43 +02:00
std : : cout < < std : : endl ;
2022-03-31 18:37:36 +03:00
}
}
2022-05-05 13:29:14 +03:00
void printEnvBindings ( const SymbolTable & st , const StaticEnv & se , const Env & env , int lvl )
2022-03-31 18:37:36 +03:00
{
std : : cout < < " Env level " < < lvl < < std : : endl ;
2022-01-04 03:29:43 +02:00
2022-03-31 18:37:36 +03:00
if ( se . up & & env . up ) {
2022-04-29 20:24:54 +03:00
std : : cout < < " static: " ;
2022-04-29 19:02:17 +03:00
printStaticEnvBindings ( st , se ) ;
2024-02-04 17:42:00 +02:00
if ( se . isWith )
printWithBindings ( st , env ) ;
2022-03-31 18:37:36 +03:00
std : : cout < < std : : endl ;
2022-04-29 19:02:17 +03:00
printEnvBindings ( st , * se . up , * env . up , + + lvl ) ;
2022-05-05 13:29:14 +03:00
} else {
2022-01-05 21:28:31 +02:00
std : : cout < < ANSI_MAGENTA ;
2022-05-05 13:29:14 +03:00
// for the top level, don't print the double underscore ones;
// they are in builtins.
for ( auto & i : se . vars )
if ( ! hasPrefix ( st [ i . first ] , " __ " ) )
std : : cout < < st [ i . first ] < < " " ;
2022-01-05 21:28:31 +02:00
std : : cout < < ANSI_NORMAL ;
2022-01-04 03:29:43 +02:00
std : : cout < < std : : endl ;
2024-02-04 17:42:00 +02:00
if ( se . isWith )
printWithBindings ( st , env ) ; // probably nothing there for the top level.
2022-01-04 03:29:43 +02:00
std : : cout < < std : : endl ;
}
2021-10-02 22:47:36 +03:00
}
2022-05-19 19:48:10 +03:00
void printEnvBindings ( const EvalState & es , const Expr & expr , const Env & env )
2021-10-02 22:47:36 +03:00
{
2021-11-25 17:23:07 +02:00
// just print the names for now
2022-05-19 19:48:10 +03:00
auto se = es . getStaticEnv ( expr ) ;
if ( se )
printEnvBindings ( es . symbols , * se , env , 0 ) ;
2022-05-05 13:29:14 +03:00
}
2022-05-06 00:43:23 +03:00
void mapStaticEnvBindings ( const SymbolTable & st , const StaticEnv & se , const Env & env , ValMap & vm )
2022-05-05 13:29:14 +03:00
{
// add bindings for the next level up first, so that the bindings for this level
// override the higher levels.
// The top level bindings (builtins) are skipped since they are added for us by initEnv()
if ( env . up & & se . up ) {
mapStaticEnvBindings ( st , * se . up , * env . up , vm ) ;
2024-02-04 17:42:00 +02:00
if ( se . isWith & & ! env . values [ 0 ] - > isThunk ( ) ) {
2022-05-05 13:29:14 +03:00
// add 'with' bindings.
2024-03-25 19:20:18 +02:00
for ( auto & j : * env . values [ 0 ] - > attrs ( ) )
2024-06-06 17:33:41 +03:00
vm . insert_or_assign ( std : : string ( st [ j . name ] ) , j . value ) ;
2022-05-05 13:29:14 +03:00
} else {
// iterate through staticenv bindings and add them.
for ( auto & i : se . vars )
2024-06-06 17:33:41 +03:00
vm . insert_or_assign ( std : : string ( st [ i . first ] ) , env . values [ i . second ] ) ;
2022-05-05 13:29:14 +03:00
}
2021-11-25 17:23:07 +02:00
}
2021-10-02 22:47:36 +03:00
}
2022-05-06 00:43:23 +03:00
std : : unique_ptr < ValMap > mapStaticEnvBindings ( const SymbolTable & st , const StaticEnv & se , const Env & env )
2022-05-05 13:29:14 +03:00
{
2022-05-06 00:43:23 +03:00
auto vm = std : : make_unique < ValMap > ( ) ;
2022-04-29 19:02:17 +03:00
mapStaticEnvBindings ( st , se , env , * vm ) ;
2021-10-12 01:32:43 +03:00
return vm ;
}
2024-02-03 06:07:42 +02:00
/**
* Sets ` inDebugger ` to true on construction and false on destruction .
*/
class DebuggerGuard {
bool & inDebugger ;
public :
DebuggerGuard ( bool & inDebugger ) : inDebugger ( inDebugger ) {
inDebugger = true ;
}
~ DebuggerGuard ( ) {
inDebugger = false ;
}
} ;
2024-05-02 00:02:43 +03:00
bool EvalState : : canDebug ( )
{
return debugRepl & & ! debugTraces . empty ( ) ;
}
void EvalState : : runDebugRepl ( const Error * error )
{
if ( ! canDebug ( ) )
return ;
assert ( ! debugTraces . empty ( ) ) ;
const DebugTrace & last = debugTraces . front ( ) ;
const Env & env = last . env ;
const Expr & expr = last . expr ;
runDebugRepl ( error , env , expr ) ;
}
2022-05-20 19:33:50 +03:00
void EvalState : : runDebugRepl ( const Error * error , const Env & env , const Expr & expr )
2022-05-20 02:01:23 +03:00
{
2024-02-03 06:07:42 +02:00
// Make sure we have a debugger to run and we're not already in a debugger.
if ( ! debugRepl | | inDebugger )
2022-05-20 19:33:50 +03:00
return ;
2022-05-25 13:32:22 +03:00
2022-05-20 02:01:23 +03:00
auto dts =
error & & expr . getPos ( )
? std : : make_unique < DebugTraceStacker > (
* this ,
DebugTrace {
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 = error - > info ( ) . pos ? error - > info ( ) . pos : positions [ expr . getPos ( ) ] ,
2022-05-20 02:01:23 +03:00
. expr = expr ,
. env = env ,
. hint = error - > info ( ) . msg ,
. isError = true
} )
: nullptr ;
if ( error )
2022-06-02 21:17:28 +03:00
{
2024-02-03 05:58:35 +02:00
printError ( " %s \n " , error - > what ( ) ) ;
2022-06-02 21:17:28 +03:00
if ( trylevel > 0 & & error - > info ( ) . level ! = lvlInfo )
2022-07-11 19:21:12 +03:00
printError ( " This exception occurred in a 'tryEval' call. Use " ANSI_GREEN " --ignore-try " ANSI_NORMAL " to skip these. \n " ) ;
2022-06-02 21:17:28 +03:00
}
2022-05-20 02:01:23 +03:00
auto se = getStaticEnv ( expr ) ;
if ( se ) {
auto vm = mapStaticEnvBindings ( symbols , * se . get ( ) , env ) ;
2024-02-03 06:07:42 +02:00
DebuggerGuard _guard ( inDebugger ) ;
2024-02-03 04:53:49 +02:00
auto exitStatus = ( debugRepl ) ( ref < EvalState > ( shared_from_this ( ) ) , * vm ) ;
switch ( exitStatus ) {
case ReplExitStatus : : QuitAll :
if ( error )
throw * error ;
throw Exit ( 0 ) ;
case ReplExitStatus : : Continue :
break ;
default :
2024-07-20 23:46:09 +03:00
unreachable ( ) ;
2024-02-03 04:53:49 +02:00
}
2022-05-20 02:01:23 +03:00
}
}
2024-02-23 03:18:27 +02:00
template < typename . . . Args >
void EvalState : : addErrorTrace ( Error & e , const Args & . . . formatArgs ) const
2007-02-27 21:10:45 +02:00
{
2024-02-23 03:18:27 +02:00
e . addTrace ( nullptr , HintFmt ( formatArgs . . . ) ) ;
2007-02-27 21:10:45 +02:00
}
2024-02-23 03:18:27 +02:00
template < typename . . . Args >
void EvalState : : addErrorTrace ( Error & e , const PosIdx pos , const Args & . . . formatArgs ) const
2013-11-12 13:51:59 +02:00
{
2024-02-23 03:18:27 +02:00
e . addTrace ( positions [ pos ] , HintFmt ( formatArgs . . . ) ) ;
2010-05-07 15:11:05 +03:00
}
2024-02-03 05:14:22 +02:00
template < typename . . . Args >
2022-05-05 13:29:14 +03:00
static std : : unique_ptr < DebugTraceStacker > makeDebugTraceStacker (
EvalState & state ,
Expr & expr ,
Env & env ,
2023-12-18 23:14:42 +02:00
std : : shared_ptr < Pos > & & pos ,
2024-02-03 05:14:22 +02:00
const Args & . . . formatArgs )
2021-12-23 18:08:41 +02:00
{
2022-05-05 13:29:14 +03:00
return std : : make_unique < DebugTraceStacker > ( state ,
DebugTrace {
2022-12-13 01:48:04 +02:00
. pos = std : : move ( pos ) ,
2022-05-05 13:29:14 +03:00
. expr = expr ,
. env = env ,
2024-02-04 06:35:19 +02:00
. hint = HintFmt ( formatArgs . . . ) ,
2022-05-05 13:29:14 +03:00
. isError = false
} ) ;
2021-12-23 18:08:41 +02:00
}
2021-12-23 00:38:49 +02:00
2022-05-05 13:29:14 +03:00
DebugTraceStacker : : DebugTraceStacker ( EvalState & evalState , DebugTrace t )
: evalState ( evalState )
, trace ( std : : move ( t ) )
2022-01-08 20:03:48 +02:00
{
2022-05-05 13:29:14 +03:00
evalState . debugTraces . push_front ( trace ) ;
2022-05-23 06:45:24 +03:00
if ( evalState . debugStop & & evalState . debugRepl )
2022-05-20 19:33:50 +03:00
evalState . runDebugRepl ( nullptr , trace . env , trace . expr ) ;
2022-01-08 20:03:48 +02:00
}
2021-12-23 00:38:49 +02:00
2022-01-04 18:39:16 +02:00
void Value : : mkString ( std : : string_view s )
2010-03-30 21:05:54 +03:00
{
2022-02-27 13:50:18 +02:00
mkString ( makeImmutableString ( s ) ) ;
2010-03-30 21:05:54 +03:00
}
2022-01-04 18:39:16 +02:00
2024-03-25 19:20:18 +02:00
static const char * * encodeContext ( const NixStringContext & context )
2010-03-30 21:05:54 +03:00
{
2010-03-31 22:52:29 +03:00
if ( ! context . empty ( ) ) {
2018-05-02 14:56:34 +03:00
size_t n = 0 ;
2024-03-25 19:20:18 +02:00
auto ctx = ( const char * * )
2015-03-19 15:11:35 +02:00
allocBytes ( ( context . size ( ) + 1 ) * sizeof ( char * ) ) ;
2015-07-17 20:24:28 +03:00
for ( auto & i : context )
2024-03-25 19:20:18 +02:00
ctx [ n + + ] = dupString ( i . to_string ( ) . c_str ( ) ) ;
ctx [ n ] = 0 ;
return ctx ;
} else
return nullptr ;
2010-03-30 21:05: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
void Value : : mkString ( std : : string_view s , const NixStringContext & context )
2021-12-27 03:04:49 +02:00
{
2024-03-25 19:20:18 +02:00
mkString ( makeImmutableString ( s ) , encodeContext ( context ) ) ;
2021-12-27 03:04:49 +02:00
}
2010-03-30 21:05: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
void Value : : mkStringMove ( const char * s , const NixStringContext & context )
2010-03-30 21:05:54 +03:00
{
2024-03-25 19:20:18 +02:00
mkString ( s , encodeContext ( context ) ) ;
2021-12-27 03:04:49 +02:00
}
2023-04-06 14:15:50 +03:00
void Value : : mkPath ( const SourcePath & path )
2010-03-30 21:05:54 +03:00
{
2023-10-18 16:32:31 +03:00
mkPath ( & * path . accessor , makeImmutableString ( path . path . abs ( ) ) ) ;
2010-03-30 21:05:54 +03:00
}
2013-10-08 15:24:53 +03:00
inline Value * EvalState : : lookupVar ( Env * env , const ExprVar & var , bool noEval )
2010-03-29 17:37:56 +03:00
{
2020-02-24 15:33:01 +02:00
for ( auto l = var . level ; l ; - - l , env = env - > up ) ;
2013-07-31 13:44:21 +03:00
if ( ! var . fromWith ) return env - > values [ var . displ ] ;
2023-12-22 19:19:53 +02:00
// This early exit defeats the `maybeThunk` optimization for variables from `with`,
// The added complexity of handling this appears to be similarly in cost, or
// the cases where applicable were insignificant in the first place.
if ( noEval ) return nullptr ;
auto * fromWith = var . fromWith ;
2013-07-31 13:44:21 +03:00
while ( 1 ) {
2023-12-22 19:19:53 +02:00
forceAttrs ( * env - > values [ 0 ] , fromWith - > pos , " while evaluating the first subexpression of a with expression " ) ;
2024-03-25 19:20:18 +02:00
if ( auto j = env - > values [ 0 ] - > attrs ( ) - > get ( var . name ) ) {
2022-03-04 20:31:59 +02:00
if ( countCalls ) attrSelects [ j - > pos ] + + ;
2013-07-31 13:44:21 +03:00
return j - > value ;
}
2023-12-22 19:19:53 +02:00
if ( ! fromWith - > parentWith )
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 < UndefinedVarError > ( " undefined variable '%1%' " , symbols [ var . name ] ) . atPos ( var . pos ) . withFrame ( * env , var ) . debugThrow ( ) ;
2023-12-22 19:19:53 +02:00
for ( size_t l = fromWith - > prevWith ; l ; - - l , env = env - > up ) ;
fromWith = fromWith - > parentWith ;
2013-07-31 13:44:21 +03:00
}
2010-03-29 17:37:56 +03:00
}
2024-03-14 20:10:31 +02:00
ListBuilder : : ListBuilder ( EvalState & state , size_t size )
: size ( size )
, elems ( size < = 2 ? inlineElems : ( Value * * ) allocBytes ( size * sizeof ( Value * ) ) )
2010-03-30 17:39:27 +03:00
{
2024-03-14 20:10:31 +02:00
state . nrListElems + = size ;
2010-03-30 17:39:27 +03:00
}
2024-03-21 00:11:54 +02:00
Value * EvalState : : getBool ( bool b ) {
return b ? & vTrue : & vFalse ;
}
2010-03-30 17:39:27 +03:00
2010-10-24 17:20:02 +03:00
unsigned long nrThunks = 0 ;
static inline void mkThunk ( Value & v , Env & env , Expr * expr )
{
2020-12-18 15:38:49 +02:00
v . mkThunk ( & env , expr ) ;
2010-10-24 17:20:02 +03:00
nrThunks + + ;
}
2010-04-12 21:30:11 +03:00
void EvalState : : mkThunk_ ( Value & v , Expr * expr )
2010-04-07 18:47:06 +03:00
{
mkThunk ( v , baseEnv , expr ) ;
}
2022-03-04 20:31:59 +02:00
void EvalState : : mkPos ( Value & v , PosIdx p )
2013-11-18 23:22:35 +02:00
{
2024-01-29 07:19:23 +02:00
auto origin = positions . originOf ( p ) ;
if ( auto path = std : : get_if < SourcePath > ( & origin ) ) {
2022-01-04 18:39:16 +02:00
auto attrs = buildBindings ( 3 ) ;
2023-04-06 16:25:06 +03:00
attrs . alloc ( sFile ) . mkString ( path - > path . abs ( ) ) ;
2024-01-29 07:19:23 +02:00
makePositionThunks ( * this , p , attrs . alloc ( sLine ) , attrs . alloc ( sColumn ) ) ;
2022-01-04 18:39:16 +02:00
v . mkAttrs ( attrs ) ;
2013-11-18 23:22:35 +02:00
} else
2022-01-04 19:40:39 +02:00
v . mkNull ( ) ;
2013-11-18 23:22: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
void EvalState : : mkStorePathString ( const StorePath & p , Value & v )
{
v . mkString (
store - > printStorePath ( p ) ,
NixStringContext {
NixStringContextElem : : Opaque { . path = p } ,
} ) ;
}
2021-03-10 06:22:56 +02:00
std : : string EvalState : : mkOutputStringRaw (
const SingleDerivedPath : : Built & b ,
std : : optional < StorePath > optStaticOutputPath ,
const ExperimentalFeatureSettings & xpSettings )
{
/* In practice, this is testing for the case of CA derivations, or
dynamic derivations . */
return optStaticOutputPath
2023-10-16 23:47:33 +03:00
? store - > printStorePath ( std : : move ( * optStaticOutputPath ) )
2021-03-10 06:22:56 +02:00
/* Downstream we would substitute this for an actual path once
we build the floating CA derivation */
: DownstreamPlaceholder : : fromSingleDerivedPathBuilt ( b , xpSettings ) . render ( ) ;
}
2023-05-11 03:47:25 +03:00
void EvalState : : mkOutputString (
Value & value ,
2021-03-10 06:22:56 +02:00
const SingleDerivedPath : : Built & b ,
2023-08-14 15:10:39 +03:00
std : : optional < StorePath > optStaticOutputPath ,
2023-07-13 06:33:43 +03:00
const ExperimentalFeatureSettings & xpSettings )
2023-05-11 03:47:25 +03:00
{
value . mkString (
2021-03-10 06:22:56 +02:00
mkOutputStringRaw ( b , optStaticOutputPath , xpSettings ) ,
NixStringContext { b } ) ;
}
std : : string EvalState : : mkSingleDerivedPathStringRaw (
const SingleDerivedPath & p )
{
return std : : visit ( overloaded {
[ & ] ( const SingleDerivedPath : : Opaque & o ) {
return store - > printStorePath ( o . path ) ;
} ,
[ & ] ( const SingleDerivedPath : : Built & b ) {
auto optStaticOutputPath = std : : visit ( overloaded {
[ & ] ( const SingleDerivedPath : : Opaque & o ) {
auto drv = store - > readDerivation ( o . path ) ;
auto i = drv . outputs . find ( b . output ) ;
if ( i = = drv . outputs . end ( ) )
throw Error ( " derivation '%s' does not have output '%s' " , b . drvPath - > to_string ( * store ) , b . output ) ;
return i - > second . path ( * store , drv . name , b . output ) ;
} ,
[ & ] ( const SingleDerivedPath : : Built & o ) - > std : : optional < StorePath > {
return std : : nullopt ;
} ,
} , b . drvPath - > raw ( ) ) ;
return mkOutputStringRaw ( b , optStaticOutputPath ) ;
}
} , p . raw ( ) ) ;
}
void EvalState : : mkSingleDerivedPathString (
const SingleDerivedPath & p ,
Value & v )
{
v . mkString (
mkSingleDerivedPathStringRaw ( p ) ,
2023-05-11 03:47:25 +03:00
NixStringContext {
2021-03-10 06:22:56 +02:00
std : : visit ( [ ] ( auto & & v ) - > NixStringContextElem { return v ; } , p ) ,
2023-05-11 03:47:25 +03:00
} ) ;
}
2010-10-24 17:20:02 +03:00
/* Create a thunk for the delayed computation of the given expression
in the given environment . But if the expression is a variable ,
then look it up right away . This significantly reduces the number
of thunks allocated . */
2012-01-04 23:24:11 +02:00
Value * Expr : : maybeThunk ( EvalState & state , Env & env )
{
Value * v = state . allocValue ( ) ;
mkThunk ( * v , env , this ) ;
return v ;
}
2010-10-24 17:20:02 +03:00
2012-01-04 23:24:11 +02:00
Value * ExprVar : : maybeThunk ( EvalState & state , Env & env )
{
2013-10-08 15:24:53 +03:00
Value * v = state . lookupVar ( & env , * this , true ) ;
2013-07-16 15:43:54 +03:00
/* The value might not be initialised in the environment yet.
In that case , ignore it . */
2021-07-22 01:31:08 +03:00
if ( v ) { state . nrAvoided + + ; return v ; }
2012-01-04 23:24:11 +02:00
return Expr : : maybeThunk ( state , env ) ;
2010-10-24 17:20:02 +03:00
}
2012-01-07 19:26:33 +02:00
Value * ExprString : : maybeThunk ( EvalState & state , Env & env )
{
2021-07-22 01:31:08 +03:00
state . nrAvoided + + ;
2012-01-07 19:26:33 +02:00
return & v ;
}
Value * ExprInt : : maybeThunk ( EvalState & state , Env & env )
{
2021-07-22 01:31:08 +03:00
state . nrAvoided + + ;
2012-01-07 19:26:33 +02:00
return & v ;
}
2016-01-05 01:40:40 +02:00
Value * ExprFloat : : maybeThunk ( EvalState & state , Env & env )
{
2021-07-22 01:31:08 +03:00
state . nrAvoided + + ;
2016-01-05 01:40:40 +02:00
return & v ;
}
2012-01-07 19:26:33 +02:00
Value * ExprPath : : maybeThunk ( EvalState & state , Env & env )
{
2021-07-22 01:31:08 +03:00
state . nrAvoided + + ;
2012-01-07 19:26:33 +02:00
return & v ;
}
2023-11-30 17:16:17 +02:00
void EvalState : : evalFile ( const SourcePath & path , Value & v , bool mustBeTrivial )
2010-03-30 12:22:33 +03:00
{
2013-10-23 14:16:46 +03:00
FileEvalCache : : iterator i ;
if ( ( i = fileEvalCache . find ( path ) ) ! = fileEvalCache . end ( ) ) {
v = i - > second ;
return ;
}
2013-09-03 13:56:33 +03:00
2023-04-06 14:15:50 +03:00
auto resolvedPath = resolveExprPath ( path ) ;
2021-09-13 15:41:28 +03:00
if ( ( i = fileEvalCache . find ( resolvedPath ) ) ! = fileEvalCache . end ( ) ) {
2011-08-06 22:45:43 +03:00
v = i - > second ;
2013-09-03 13:56:33 +03:00
return ;
}
2021-09-13 15:41:28 +03:00
printTalkative ( " evaluating file '%1%' " , resolvedPath ) ;
2018-06-11 17:06:01 +03:00
Expr * e = nullptr ;
2021-09-13 15:41:28 +03:00
auto j = fileParseCache . find ( resolvedPath ) ;
2018-06-11 17:06:01 +03:00
if ( j ! = fileParseCache . end ( ) )
e = j - > second ;
if ( ! e )
2023-11-30 17:16:17 +02:00
e = parseExprFromFile ( resolvedPath ) ;
2021-09-13 15:41:28 +03:00
2024-06-06 20:12:36 +03:00
fileParseCache . emplace ( resolvedPath , e ) ;
2018-06-11 17:06:01 +03:00
2013-09-03 13:56:33 +03:00
try {
2022-05-23 06:45:24 +03:00
auto dts = debugRepl
2022-05-05 13:29:14 +03:00
? makeDebugTraceStacker (
* this ,
* e ,
this - > baseEnv ,
2023-12-18 23:14:42 +02:00
e - > getPos ( ) ? std : : make_shared < Pos > ( positions [ e - > getPos ( ) ] ) : nullptr ,
2023-04-06 14:15:50 +03:00
" while evaluating the file '%1%': " , resolvedPath . to_string ( ) )
2022-05-05 13:29:14 +03:00
: nullptr ;
2021-12-23 00:38:49 +02:00
2019-09-09 18:34:38 +03:00
// Enforce that 'flake.nix' is a direct attrset, not a
// computation.
if ( mustBeTrivial & &
! ( dynamic_cast < ExprAttrs * > ( 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
error < EvalError > ( " file '%s' must be an attribute set " , path ) . debugThrow ( ) ;
2013-09-03 13:56:33 +03:00
eval ( e , v ) ;
} catch ( Error & e ) {
2023-04-06 14:15:50 +03:00
addErrorTrace ( e , " while evaluating the file '%1%': " , resolvedPath . to_string ( ) ) ;
2013-09-03 13:56:33 +03:00
throw ;
}
2013-10-23 14:16:46 +03:00
2024-06-06 20:12:36 +03:00
fileEvalCache . emplace ( resolvedPath , v ) ;
if ( path ! = resolvedPath ) fileEvalCache . emplace ( path , v ) ;
2013-09-02 19:34:04 +03:00
}
2023-10-18 18:34:58 +03:00
void EvalState : : resetFileCache ( )
{
fileEvalCache . clear ( ) ;
fileParseCache . clear ( ) ;
}
2010-04-12 21:30:11 +03:00
void EvalState : : eval ( Expr * e , Value & v )
{
2012-02-04 15:50:25 +02:00
e - > eval ( * this , baseEnv , v ) ;
2010-04-12 21:30:11 +03:00
}
2010-03-29 17:37:56 +03:00
2010-04-12 21:30:11 +03:00
2023-01-19 14:23:04 +02:00
inline bool EvalState : : evalBool ( Env & env , Expr * e , const PosIdx pos , std : : string_view errorCtx )
2010-04-16 18:13:47 +03:00
{
2023-01-19 14:23:04 +02:00
try {
Value v ;
e - > eval ( * this , env , v ) ;
if ( v . type ( ) ! = nBool )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a Boolean but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . withFrame ( env , * e ) . debugThrow ( ) ;
2024-03-25 19:20:18 +02:00
return v . boolean ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2023-01-18 02:19:07 +02:00
}
2023-01-19 14:23:04 +02:00
inline void EvalState : : evalAttrs ( Env & env , Expr * e , Value & v , const PosIdx pos , std : : string_view errorCtx )
2023-01-18 02:19:07 +02:00
{
2023-01-19 14:23:04 +02:00
try {
e - > eval ( * this , env , v ) ;
if ( v . type ( ) ! = nAttrs )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a set but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . withFrame ( env , * e ) . debugThrow ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2010-04-16 18:13:47 +03:00
}
2010-04-13 01:03:27 +03:00
void Expr : : eval ( EvalState & state , Env & env , Value & v )
{
2024-07-20 23:46:09 +03:00
unreachable ( ) ;
2010-04-13 01:03:27 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprInt : : eval ( EvalState & state , Env & env , Value & v )
{
2012-01-07 19:26:33 +02:00
v = this - > v ;
2010-04-12 21:30:11 +03:00
}
2016-01-05 01:40:40 +02:00
void ExprFloat : : eval ( EvalState & state , Env & env , Value & v )
{
v = this - > v ;
}
2010-04-12 21:30:11 +03:00
void ExprString : : eval ( EvalState & state , Env & env , Value & v )
{
2012-01-07 19:26:33 +02:00
v = this - > v ;
2010-04-12 21:30:11 +03:00
}
void ExprPath : : eval ( EvalState & state , Env & env , Value & v )
{
2012-01-07 19:26:33 +02:00
v = this - > v ;
2010-04-12 21:30:11 +03:00
}
2024-01-27 17:33:34 +02:00
Env * ExprAttrs : : buildInheritFromEnv ( EvalState & state , Env & up )
{
Env & inheritEnv = state . allocEnv ( inheritFromExprs - > size ( ) ) ;
inheritEnv . up = & up ;
Displacement displ = 0 ;
for ( auto from : * inheritFromExprs )
inheritEnv . values [ displ + + ] = from - > maybeThunk ( state , up ) ;
return & inheritEnv ;
}
2010-04-12 21:30:11 +03:00
void ExprAttrs : : eval ( EvalState & state , Env & env , Value & v )
{
2024-03-25 19:20:18 +02:00
auto bindings = state . buildBindings ( attrs . size ( ) + dynamicAttrs . size ( ) ) ;
2022-01-04 21:29:17 +02:00
auto dynamicEnv = & env ;
2024-03-25 19:20:18 +02:00
bool sort = false ;
2010-04-15 02:25:05 +03:00
2010-04-12 21:30:11 +03:00
if ( recursive ) {
/* Create a new environment that contains the attributes in
this ` rec ' . */
2010-10-24 22:52:33 +03:00
Env & env2 ( state . allocEnv ( attrs . size ( ) ) ) ;
2010-04-12 21:30:11 +03:00
env2 . up = & env ;
Dynamic attrs
This adds new syntax for attribute names:
* attrs."${name}" => getAttr name attrs
* attrs ? "${name}" => isAttrs attrs && hasAttr attrs name
* attrs."${name}" or def => if attrs ? "${name}" then attrs."${name}" else def
* { "${name}" = value; } => listToAttrs [{ inherit name value; }]
Of course, it's a bit more complicated than that. The attribute chains
can be arbitrarily long and contain combinations of static and dynamic
parts (e.g. attrs."${foo}".bar."${baz}" or qux), which is relatively
straightforward for the getAttrs/hasAttrs cases but is more complex for
the listToAttrs case due to rules about duplicate attribute definitions.
For attribute sets with dynamic attribute names, duplicate static
attributes are detected at parse time while duplicate dynamic attributes
are detected when the attribute set is forced. So, for example, { a =
null; a.b = null; "${"c"}" = true; } will be a parse-time error, while
{ a = {}; "${"a"}".b = null; c = true; } will be an eval-time error
(technically that case could theoretically be detected at parse time,
but the general case would require full evaluation). Moreover, duplicate
dynamic attributes are not allowed even in cases where they would be
with static attributes ({ a.b.d = true; a.b.c = false; } is legal, but {
a."${"b"}".d = true; a."${"b"}".c = false; } is not). This restriction
might be relaxed in the future in cases where the static variant would
not be an error, but it is not obvious that that is desirable.
Finally, recursive attribute sets with dynamic attributes have the
static attributes in scope but not the dynamic ones. So rec { a = true;
"${"b"}" = a; } is equivalent to { a = true; b = true; } but rec {
"${"a"}" = true; b = a; } would be an error or use a from the
surrounding scope if it exists.
Note that the getAttr, getAttr or default, and hasAttr are all
implemented purely in the parser as syntactic sugar, while attribute
sets with dynamic attribute names required changes to the AST to be
implemented cleanly.
This is an alternative solution to and closes #167
Signed-off-by: Shea Levy <shea@shealevy.com>
2013-09-21 06:25:30 +03:00
dynamicEnv = & env2 ;
2024-01-27 17:33:34 +02:00
Env * inheritEnv = inheritFromExprs ? buildInheritFromEnv ( state , env2 ) : nullptr ;
2010-04-12 21:30:11 +03:00
2010-10-24 22:52:33 +03:00
AttrDefs : : iterator overrides = attrs . find ( state . sOverrides ) ;
bool hasOverrides = overrides ! = attrs . end ( ) ;
/* The recursive attributes are evaluated in the new
environment , while the inherited attributes are evaluated
in the original environment . */
2020-02-24 15:33:01 +02:00
Displacement displ = 0 ;
2015-07-17 20:24:28 +03:00
for ( auto & i : attrs ) {
2013-07-16 00:10:18 +03:00
Value * vAttr ;
2024-02-26 16:33:52 +02:00
if ( hasOverrides & & i . second . kind ! = AttrDef : : Kind : : Inherited ) {
2013-07-16 00:10:18 +03:00
vAttr = state . allocValue ( ) ;
2024-01-27 17:33:34 +02:00
mkThunk ( * vAttr , * i . second . chooseByKind ( & env2 , & env , inheritEnv ) , i . second . e ) ;
2013-07-16 00:10:18 +03:00
} else
2024-01-27 17:33:34 +02:00
vAttr = i . second . e - > maybeThunk ( state , * i . second . chooseByKind ( & env2 , & env , inheritEnv ) ) ;
2013-07-16 00:10:18 +03:00
env2 . values [ displ + + ] = vAttr ;
2024-03-25 19:20:18 +02:00
bindings . insert ( i . first , vAttr , i . second . pos ) ;
2013-07-16 00:10:18 +03:00
}
2010-05-15 11:10:12 +03:00
/* If the rec contains an attribute called `__overrides', then
evaluate it , and add the attributes in that set to the rec .
This allows overriding of recursive attributes , which is
otherwise not possible . ( You can use the // operator to
replace an attribute , but other attributes in the rec will
still reference the original value , because that value has
been substituted into the bodies of the other attributes .
Hence we need __overrides . ) */
2010-10-24 22:52:33 +03:00
if ( hasOverrides ) {
2024-03-25 19:20:18 +02:00
Value * vOverrides = ( * bindings . bindings ) [ overrides - > second . displ ] . value ;
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * vOverrides , [ & ] ( ) { return vOverrides - > determinePos ( noPos ) ; } , " while evaluating the `__overrides` attribute " ) ;
2024-03-25 19:20:18 +02:00
bindings . grow ( state . allocBindings ( bindings . capacity ( ) + vOverrides - > attrs ( ) - > size ( ) ) ) ;
for ( auto & i : * vOverrides - > attrs ( ) ) {
2014-09-19 17:49:41 +03:00
AttrDefs : : iterator j = attrs . find ( i . name ) ;
2010-10-24 22:52:33 +03:00
if ( j ! = attrs . end ( ) ) {
2024-03-25 19:20:18 +02:00
( * bindings . bindings ) [ j - > second . displ ] = i ;
2014-09-19 17:49:41 +03:00
env2 . values [ j - > second . displ ] = i . value ;
2010-10-24 22:52:33 +03:00
} else
2024-03-25 19:20:18 +02:00
bindings . push_back ( i ) ;
2010-05-15 11:10:12 +03:00
}
2024-03-25 19:20:18 +02:00
sort = true ;
2010-05-15 11:10:12 +03:00
}
2010-04-12 21:30:11 +03:00
}
2024-01-27 17:33:34 +02:00
else {
2024-01-27 17:33:34 +02:00
Env * inheritEnv = inheritFromExprs ? buildInheritFromEnv ( state , env ) : nullptr ;
2024-03-25 19:20:18 +02:00
for ( auto & i : attrs )
bindings . insert (
i . first ,
i . second . e - > maybeThunk ( state , * i . second . chooseByKind ( & env , & env , inheritEnv ) ) ,
i . second . pos ) ;
2024-01-27 17:33:34 +02:00
}
Dynamic attrs
This adds new syntax for attribute names:
* attrs."${name}" => getAttr name attrs
* attrs ? "${name}" => isAttrs attrs && hasAttr attrs name
* attrs."${name}" or def => if attrs ? "${name}" then attrs."${name}" else def
* { "${name}" = value; } => listToAttrs [{ inherit name value; }]
Of course, it's a bit more complicated than that. The attribute chains
can be arbitrarily long and contain combinations of static and dynamic
parts (e.g. attrs."${foo}".bar."${baz}" or qux), which is relatively
straightforward for the getAttrs/hasAttrs cases but is more complex for
the listToAttrs case due to rules about duplicate attribute definitions.
For attribute sets with dynamic attribute names, duplicate static
attributes are detected at parse time while duplicate dynamic attributes
are detected when the attribute set is forced. So, for example, { a =
null; a.b = null; "${"c"}" = true; } will be a parse-time error, while
{ a = {}; "${"a"}".b = null; c = true; } will be an eval-time error
(technically that case could theoretically be detected at parse time,
but the general case would require full evaluation). Moreover, duplicate
dynamic attributes are not allowed even in cases where they would be
with static attributes ({ a.b.d = true; a.b.c = false; } is legal, but {
a."${"b"}".d = true; a."${"b"}".c = false; } is not). This restriction
might be relaxed in the future in cases where the static variant would
not be an error, but it is not obvious that that is desirable.
Finally, recursive attribute sets with dynamic attributes have the
static attributes in scope but not the dynamic ones. So rec { a = true;
"${"b"}" = a; } is equivalent to { a = true; b = true; } but rec {
"${"a"}" = true; b = a; } would be an error or use a from the
surrounding scope if it exists.
Note that the getAttr, getAttr or default, and hasAttr are all
implemented purely in the parser as syntactic sugar, while attribute
sets with dynamic attribute names required changes to the AST to be
implemented cleanly.
This is an alternative solution to and closes #167
Signed-off-by: Shea Levy <shea@shealevy.com>
2013-09-21 06:25:30 +03:00
2014-04-04 23:19:33 +03:00
/* Dynamic attrs apply *after* rec and __overrides. */
2015-07-17 20:24:28 +03:00
for ( auto & i : dynamicAttrs ) {
Dynamic attrs
This adds new syntax for attribute names:
* attrs."${name}" => getAttr name attrs
* attrs ? "${name}" => isAttrs attrs && hasAttr attrs name
* attrs."${name}" or def => if attrs ? "${name}" then attrs."${name}" else def
* { "${name}" = value; } => listToAttrs [{ inherit name value; }]
Of course, it's a bit more complicated than that. The attribute chains
can be arbitrarily long and contain combinations of static and dynamic
parts (e.g. attrs."${foo}".bar."${baz}" or qux), which is relatively
straightforward for the getAttrs/hasAttrs cases but is more complex for
the listToAttrs case due to rules about duplicate attribute definitions.
For attribute sets with dynamic attribute names, duplicate static
attributes are detected at parse time while duplicate dynamic attributes
are detected when the attribute set is forced. So, for example, { a =
null; a.b = null; "${"c"}" = true; } will be a parse-time error, while
{ a = {}; "${"a"}".b = null; c = true; } will be an eval-time error
(technically that case could theoretically be detected at parse time,
but the general case would require full evaluation). Moreover, duplicate
dynamic attributes are not allowed even in cases where they would be
with static attributes ({ a.b.d = true; a.b.c = false; } is legal, but {
a."${"b"}".d = true; a."${"b"}".c = false; } is not). This restriction
might be relaxed in the future in cases where the static variant would
not be an error, but it is not obvious that that is desirable.
Finally, recursive attribute sets with dynamic attributes have the
static attributes in scope but not the dynamic ones. So rec { a = true;
"${"b"}" = a; } is equivalent to { a = true; b = true; } but rec {
"${"a"}" = true; b = a; } would be an error or use a from the
surrounding scope if it exists.
Note that the getAttr, getAttr or default, and hasAttr are all
implemented purely in the parser as syntactic sugar, while attribute
sets with dynamic attribute names required changes to the AST to be
implemented cleanly.
This is an alternative solution to and closes #167
Signed-off-by: Shea Levy <shea@shealevy.com>
2013-09-21 06:25:30 +03:00
Value nameVal ;
2015-07-17 20:24:28 +03:00
i . nameExpr - > eval ( state , * dynamicEnv , nameVal ) ;
2015-07-31 18:32:25 +03:00
state . forceValue ( nameVal , i . pos ) ;
2020-12-17 15:45:45 +02:00
if ( nameVal . type ( ) = = nNull )
2014-10-05 02:04:58 +03:00
continue ;
2023-01-19 14:23:04 +02:00
state . forceStringNoCtx ( nameVal , i . pos , " while evaluating the name of a dynamic attribute " ) ;
2023-09-26 04:30:41 +03:00
auto nameSym = state . symbols . create ( nameVal . string_view ( ) ) ;
2024-03-25 19:20:18 +02:00
if ( sort )
// FIXME: inefficient
bindings . bindings - > sort ( ) ;
if ( auto j = bindings . bindings - > get ( nameSym ) )
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 > ( " dynamic attribute '%1%' already defined at %2% " , state . symbols [ nameSym ] , state . positions [ j - > pos ] ) . atPos ( i . pos ) . withFrame ( env , * this ) . debugThrow ( ) ;
Dynamic attrs
This adds new syntax for attribute names:
* attrs."${name}" => getAttr name attrs
* attrs ? "${name}" => isAttrs attrs && hasAttr attrs name
* attrs."${name}" or def => if attrs ? "${name}" then attrs."${name}" else def
* { "${name}" = value; } => listToAttrs [{ inherit name value; }]
Of course, it's a bit more complicated than that. The attribute chains
can be arbitrarily long and contain combinations of static and dynamic
parts (e.g. attrs."${foo}".bar."${baz}" or qux), which is relatively
straightforward for the getAttrs/hasAttrs cases but is more complex for
the listToAttrs case due to rules about duplicate attribute definitions.
For attribute sets with dynamic attribute names, duplicate static
attributes are detected at parse time while duplicate dynamic attributes
are detected when the attribute set is forced. So, for example, { a =
null; a.b = null; "${"c"}" = true; } will be a parse-time error, while
{ a = {}; "${"a"}".b = null; c = true; } will be an eval-time error
(technically that case could theoretically be detected at parse time,
but the general case would require full evaluation). Moreover, duplicate
dynamic attributes are not allowed even in cases where they would be
with static attributes ({ a.b.d = true; a.b.c = false; } is legal, but {
a."${"b"}".d = true; a."${"b"}".c = false; } is not). This restriction
might be relaxed in the future in cases where the static variant would
not be an error, but it is not obvious that that is desirable.
Finally, recursive attribute sets with dynamic attributes have the
static attributes in scope but not the dynamic ones. So rec { a = true;
"${"b"}" = a; } is equivalent to { a = true; b = true; } but rec {
"${"a"}" = true; b = a; } would be an error or use a from the
surrounding scope if it exists.
Note that the getAttr, getAttr or default, and hasAttr are all
implemented purely in the parser as syntactic sugar, while attribute
sets with dynamic attribute names required changes to the AST to be
implemented cleanly.
This is an alternative solution to and closes #167
Signed-off-by: Shea Levy <shea@shealevy.com>
2013-09-21 06:25:30 +03:00
2015-07-17 20:24:28 +03:00
i . valueExpr - > setName ( nameSym ) ;
Dynamic attrs
This adds new syntax for attribute names:
* attrs."${name}" => getAttr name attrs
* attrs ? "${name}" => isAttrs attrs && hasAttr attrs name
* attrs."${name}" or def => if attrs ? "${name}" then attrs."${name}" else def
* { "${name}" = value; } => listToAttrs [{ inherit name value; }]
Of course, it's a bit more complicated than that. The attribute chains
can be arbitrarily long and contain combinations of static and dynamic
parts (e.g. attrs."${foo}".bar."${baz}" or qux), which is relatively
straightforward for the getAttrs/hasAttrs cases but is more complex for
the listToAttrs case due to rules about duplicate attribute definitions.
For attribute sets with dynamic attribute names, duplicate static
attributes are detected at parse time while duplicate dynamic attributes
are detected when the attribute set is forced. So, for example, { a =
null; a.b = null; "${"c"}" = true; } will be a parse-time error, while
{ a = {}; "${"a"}".b = null; c = true; } will be an eval-time error
(technically that case could theoretically be detected at parse time,
but the general case would require full evaluation). Moreover, duplicate
dynamic attributes are not allowed even in cases where they would be
with static attributes ({ a.b.d = true; a.b.c = false; } is legal, but {
a."${"b"}".d = true; a."${"b"}".c = false; } is not). This restriction
might be relaxed in the future in cases where the static variant would
not be an error, but it is not obvious that that is desirable.
Finally, recursive attribute sets with dynamic attributes have the
static attributes in scope but not the dynamic ones. So rec { a = true;
"${"b"}" = a; } is equivalent to { a = true; b = true; } but rec {
"${"a"}" = true; b = a; } would be an error or use a from the
surrounding scope if it exists.
Note that the getAttr, getAttr or default, and hasAttr are all
implemented purely in the parser as syntactic sugar, while attribute
sets with dynamic attribute names required changes to the AST to be
implemented cleanly.
This is an alternative solution to and closes #167
Signed-off-by: Shea Levy <shea@shealevy.com>
2013-09-21 06:25:30 +03:00
/* Keep sorted order so find can catch duplicates */
2024-03-25 19:20:18 +02:00
bindings . insert ( nameSym , i . valueExpr - > maybeThunk ( state , * dynamicEnv ) , i . pos ) ;
sort = true ;
2010-04-12 21:30:11 +03:00
}
2021-01-08 23:27:00 +02:00
2024-03-25 19:20:18 +02:00
bindings . bindings - > pos = pos ;
v . mkAttrs ( sort ? bindings . finish ( ) : bindings . alreadySorted ( ) ) ;
2010-04-12 21:30:11 +03:00
}
2010-04-13 16:42:25 +03:00
void ExprLet : : eval ( EvalState & state , Env & env , Value & v )
{
/* Create a new environment that contains the attributes in this
` let ' . */
2010-10-24 22:52:33 +03:00
Env & env2 ( state . allocEnv ( attrs - > attrs . size ( ) ) ) ;
2010-04-13 16:42:25 +03:00
env2 . up = & env ;
2010-04-14 17:42:32 +03:00
2024-01-27 17:33:34 +02:00
Env * inheritEnv = attrs - > inheritFromExprs ? attrs - > buildInheritFromEnv ( state , env2 ) : nullptr ;
2010-10-24 22:52:33 +03:00
/* The recursive attributes are evaluated in the new environment,
while the inherited attributes are evaluated in the original
2010-04-13 16:42:25 +03:00
environment . */
2020-02-24 15:33:01 +02:00
Displacement displ = 0 ;
2024-01-27 17:33:34 +02:00
for ( auto & i : attrs - > attrs ) {
env2 . values [ displ + + ] = i . second . e - > maybeThunk (
state ,
2024-01-27 17:33:34 +02:00
* i . second . chooseByKind ( & env2 , & env , inheritEnv ) ) ;
2024-01-27 17:33:34 +02:00
}
2010-04-13 16:42:25 +03:00
2024-02-03 05:14:22 +02:00
auto dts = state . debugRepl
? makeDebugTraceStacker (
state ,
* this ,
env2 ,
getPos ( )
? std : : make_shared < Pos > ( state . positions [ getPos ( ) ] )
: nullptr ,
" while evaluating a '%1%' expression " ,
" let "
)
: nullptr ;
2012-02-04 15:50:25 +02:00
body - > eval ( state , env2 , v ) ;
2010-04-13 16:42:25 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprList : : eval ( EvalState & state , Env & env , Value & v )
{
2024-03-14 20:10:31 +02:00
auto list = state . buildList ( elems . size ( ) ) ;
for ( const auto & [ n , v2 ] : enumerate ( list ) )
v2 = elems [ n ] - > maybeThunk ( state , env ) ;
v . mkList ( list ) ;
2010-04-12 21:30:11 +03:00
}
Optimize empty list constants
This avoids a Value allocation for empty list constants. During a `nix
search nixpkgs`, about 82% of all thunked lists are empty, so this
removes about 3 million Value allocations.
Performance comparison on `nix search github:NixOS/nixpkgs/e1fa12d4f6c6fe19ccb59cac54b5b3f25e160870 --no-eval-cache`:
maximum RSS: median = 3845432.0000 mean = 3845432.0000 stddev = 0.0000 min = 3845432.0000 max = 3845432.0000 [rejected?, p=0.00000, Δ=-70084.00000±0.00000]
soft page faults: median = 965395.0000 mean = 965394.6667 stddev = 1.1181 min = 965392.0000 max = 965396.0000 [rejected?, p=0.00000, Δ=-17929.77778±38.59610]
system CPU time: median = 1.8029 mean = 1.7702 stddev = 0.0621 min = 1.6749 max = 1.8417 [rejected, p=0.00064, Δ=-0.12873±0.09905]
user CPU time: median = 14.1022 mean = 14.0633 stddev = 0.1869 min = 13.8118 max = 14.3190 [not rejected, p=0.03006, Δ=-0.18248±0.24928]
elapsed time: median = 15.8205 mean = 15.8618 stddev = 0.2312 min = 15.5033 max = 16.1670 [not rejected, p=0.00558, Δ=-0.28963±0.29434]
2024-01-02 13:39:16 +02:00
Value * ExprList : : maybeThunk ( EvalState & state , Env & env )
{
if ( elems . empty ( ) ) {
return & state . vEmptyList ;
}
return Expr : : maybeThunk ( state , env ) ;
}
2010-04-12 21:30:11 +03:00
void ExprVar : : eval ( EvalState & state , Env & env , Value & v )
{
2013-10-08 15:24:53 +03:00
Value * v2 = state . lookupVar ( & env , * this , false ) ;
2015-07-31 18:32:25 +03:00
state . forceValue ( * v2 , pos ) ;
2010-04-14 18:14:23 +03:00
v = * v2 ;
2010-04-12 21:30:11 +03:00
}
2022-02-25 17:00:00 +02:00
static std : : string showAttrPath ( EvalState & state , Env & env , const AttrPath & attrPath )
2015-03-06 15:24:08 +02:00
{
std : : ostringstream out ;
bool first = true ;
for ( auto & i : attrPath ) {
if ( ! first ) out < < ' . ' ; else first = false ;
try {
2022-03-05 15:40:24 +02:00
out < < state . symbols [ getName ( i , state , env ) ] ;
2015-03-06 15:24:08 +02:00
} catch ( Error & e ) {
2022-03-05 15:40:24 +02:00
assert ( ! i . symbol ) ;
out < < " \" ${ " ;
i . expr - > show ( state . symbols , out ) ;
out < < " } \" " ;
2015-03-06 15:24:08 +02:00
}
}
return out . str ( ) ;
}
2010-04-12 21:30:11 +03:00
void ExprSelect : : eval ( EvalState & state , Env & env , Value & v )
{
2011-07-06 15:28:57 +03:00
Value vTmp ;
2022-03-04 20:31:59 +02:00
PosIdx pos2 ;
2011-07-06 15:28:57 +03:00
Value * vAttrs = & vTmp ;
2012-02-04 15:50:25 +02:00
e - > eval ( state , env , vTmp ) ;
2011-07-06 15:28:57 +03:00
try {
2022-05-23 06:45:24 +03:00
auto dts = state . debugRepl
2022-05-05 13:29:14 +03:00
? makeDebugTraceStacker (
state ,
* this ,
env ,
2024-02-03 03:49:10 +02:00
state . positions [ getPos ( ) ] ,
2022-05-05 13:29:14 +03:00
" while evaluating the attribute '%1%' " ,
showAttrPath ( state , env , attrPath ) )
2022-04-09 00:46:12 +03:00
: nullptr ;
2013-09-02 17:29:15 +03:00
2015-07-17 20:24:28 +03:00
for ( auto & i : attrPath ) {
2021-07-22 01:31:08 +03:00
state . nrLookups + + ;
2024-03-25 19:20:18 +02:00
const Attr * j ;
2022-03-05 15:40:24 +02:00
auto name = getName ( i , state , env ) ;
2011-07-13 15:19:57 +03:00
if ( def ) {
2015-07-31 18:32:25 +03:00
state . forceValue ( * vAttrs , pos ) ;
2020-12-17 15:45:45 +02:00
if ( vAttrs - > type ( ) ! = nAttrs | |
2024-03-25 19:20:18 +02:00
! ( j = vAttrs - > attrs ( ) - > get ( name ) ) )
2011-07-13 15:19:57 +03:00
{
2012-02-04 15:50:25 +02:00
def - > eval ( state , env , v ) ;
2011-07-13 15:19:57 +03:00
return ;
}
} else {
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * vAttrs , pos , " while selecting an attribute " ) ;
2024-03-25 19:20:18 +02:00
if ( ! ( j = vAttrs - > attrs ( ) - > get ( name ) ) ) {
2022-03-08 07:16:51 +02:00
std : : set < std : : string > allAttrNames ;
2024-03-25 19:20:18 +02:00
for ( auto & attr : * vAttrs - > attrs ( ) )
2024-06-06 17:33:41 +03:00
allAttrNames . insert ( std : : string ( state . symbols [ attr . name ] ) ) ;
2023-01-19 14:23:04 +02:00
auto suggestions = Suggestions : : bestMatches ( allAttrNames , state . symbols [ name ] ) ;
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 > ( " attribute '%1%' missing " , state . symbols [ name ] )
. atPos ( pos ) . withSuggestions ( suggestions ) . withFrame ( env , * this ) . debugThrow ( ) ;
2022-03-08 07:16:51 +02:00
}
2011-07-13 15:19:57 +03:00
}
2011-07-06 15:28:57 +03:00
vAttrs = j - > value ;
2014-04-04 23:52:14 +03:00
pos2 = j - > pos ;
2022-03-04 20:31:59 +02:00
if ( state . countCalls ) state . attrSelects [ pos2 ] + + ;
2011-07-06 15:28:57 +03:00
}
2013-09-02 17:29:15 +03:00
2022-03-04 20:31:59 +02:00
state . forceValue ( * vAttrs , ( pos2 ? pos2 : this - > pos ) ) ;
2013-09-02 17:29:15 +03:00
2010-04-12 21:30:11 +03:00
} catch ( Error & e ) {
2022-12-13 01:48:04 +02:00
if ( pos2 ) {
auto pos2r = state . positions [ pos2 ] ;
2023-04-06 16:25:06 +03:00
auto origin = std : : get_if < SourcePath > ( & pos2r . origin ) ;
if ( ! ( origin & & * origin = = state . derivationInternal ) )
2022-12-13 01:48:04 +02:00
state . addErrorTrace ( e , pos2 , " while evaluating the attribute '%1%' " ,
showAttrPath ( state , env , attrPath ) ) ;
}
2010-04-12 21:30:11 +03:00
throw ;
}
2013-09-02 17:29:15 +03:00
2011-07-06 15:28:57 +03:00
v = * vAttrs ;
2010-04-12 21:30:11 +03:00
}
2024-07-09 20:25:45 +03:00
Symbol ExprSelect : : evalExceptFinalSelect ( EvalState & state , Env & env , Value & attrs )
{
Value vTmp ;
Symbol name = getName ( attrPath [ attrPath . size ( ) - 1 ] , state , env ) ;
if ( attrPath . size ( ) = = 1 ) {
e - > eval ( state , env , vTmp ) ;
} else {
ExprSelect init ( * this ) ;
init . attrPath . pop_back ( ) ;
init . eval ( state , env , vTmp ) ;
}
attrs = vTmp ;
return name ;
}
2010-04-12 21:30:11 +03:00
2010-04-13 00:21:24 +03:00
void ExprOpHasAttr : : eval ( EvalState & state , Env & env , Value & v )
{
2011-07-06 13:58:17 +03:00
Value vTmp ;
Value * vAttrs = & vTmp ;
2012-02-04 15:50:25 +02:00
e - > eval ( state , env , vTmp ) ;
2011-07-06 13:58:17 +03:00
2015-07-17 20:24:28 +03:00
for ( auto & i : attrPath ) {
2023-12-07 20:01:42 +02:00
state . forceValue ( * vAttrs , getPos ( ) ) ;
2024-03-25 19:20:18 +02:00
const Attr * j ;
2022-03-05 15:40:24 +02:00
auto name = getName ( i , state , env ) ;
2024-03-25 19:20:18 +02:00
if ( vAttrs - > type ( ) = = nAttrs & &
( j = vAttrs - > attrs ( ) - > get ( name ) ) )
2011-07-06 13:58:17 +03:00
{
2024-03-25 19:20:18 +02:00
vAttrs = j - > value ;
} else {
2022-01-04 19:40:39 +02:00
v . mkBool ( false ) ;
2011-07-06 13:58:17 +03:00
return ;
}
}
2013-09-02 17:29:15 +03:00
2022-01-04 19:40:39 +02:00
v . mkBool ( true ) ;
2010-04-13 00:21:24 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprLambda : : eval ( EvalState & state , Env & env , Value & v )
{
2020-12-18 15:38:49 +02:00
v . mkLambda ( & env , this ) ;
2010-04-12 21:30:11 +03:00
}
2023-12-15 21:52:21 +02:00
namespace {
/** Increments a count on construction and decrements on destruction.
*/
class CallDepth {
size_t & count ;
public :
CallDepth ( size_t & count ) : count ( count ) {
+ + count ;
}
~ CallDepth ( ) {
- - count ;
}
} ;
} ;
2010-04-12 21:30:11 +03:00
2022-03-04 20:31:59 +02:00
void EvalState : : callFunction ( Value & fun , size_t nrArgs , Value * * args , Value & vRes , const PosIdx pos )
2010-04-12 21:30:11 +03:00
{
2024-06-14 19:41:09 +03:00
if ( callDepth > settings . maxCallDepth )
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 < EvalError > ( " stack overflow; max-call-depth exceeded " ) . atPos ( pos ) . debugThrow ( ) ;
2023-12-15 21:52:21 +02:00
CallDepth _level ( callDepth ) ;
2024-06-14 19:41:09 +03:00
auto trace = settings . traceFunctionCalls
2022-03-04 20:31:59 +02:00
? std : : make_unique < FunctionCallTrace > ( positions [ pos ] )
: nullptr ;
2013-11-07 19:04:36 +02:00
2020-02-24 02:32:01 +02:00
forceValue ( fun , pos ) ;
2013-11-07 19:04:36 +02:00
2020-02-24 02:32:01 +02:00
Value vCur ( fun ) ;
2010-03-29 17:37:56 +03:00
2020-02-24 02:32:01 +02:00
auto makeAppChain = [ & ] ( )
{
vRes = vCur ;
for ( size_t i = 0 ; i < nrArgs ; + + i ) {
auto fun2 = allocValue ( ) ;
* fun2 = vRes ;
vRes . mkPrimOpApp ( fun2 , args [ i ] ) ;
}
} ;
2020-08-05 22:26:17 +03:00
2024-03-25 19:20:18 +02:00
const Attr * functor ;
2019-04-12 19:31:33 +03:00
2020-02-24 02:32:01 +02:00
while ( nrArgs > 0 ) {
2018-07-07 00:49:51 +03:00
2020-02-24 02:32:01 +02:00
if ( vCur . isLambda ( ) ) {
2013-09-02 17:29:15 +03:00
2024-03-25 19:20:18 +02:00
ExprLambda & lambda ( * vCur . payload . lambda . fun ) ;
2014-10-16 05:04:48 +03:00
2020-02-24 02:32:01 +02:00
auto size =
2022-03-05 15:40:24 +02:00
( ! lambda . arg ? 0 : 1 ) +
2020-02-24 02:32:01 +02:00
( lambda . hasFormals ( ) ? lambda . formals - > formals . size ( ) : 0 ) ;
Env & env2 ( allocEnv ( size ) ) ;
2024-03-25 19:20:18 +02:00
env2 . up = vCur . payload . lambda . env ;
2010-03-30 16:47:59 +03:00
2020-02-24 15:33:01 +02:00
Displacement displ = 0 ;
2013-11-12 13:51:59 +02:00
2020-02-24 02:32:01 +02:00
if ( ! lambda . hasFormals ( ) )
env2 . values [ displ + + ] = args [ 0 ] ;
else {
2023-01-19 14:23:04 +02:00
try {
forceAttrs ( * args [ 0 ] , lambda . pos , " while evaluating the value passed for the lambda argument " ) ;
} catch ( Error & e ) {
if ( pos ) e . addTrace ( positions [ pos ] , " from call site " ) ;
throw ;
}
2010-03-30 16:47:59 +03:00
2022-03-05 15:40:24 +02:00
if ( lambda . arg )
2020-02-24 02:32:01 +02:00
env2 . values [ displ + + ] = args [ 0 ] ;
2010-04-14 17:42:32 +03:00
2020-02-24 02:32:01 +02:00
/* For each formal argument, get the actual argument. If
there is no matching actual argument but the formal
argument has a default , use the default . */
size_t attrsUsed = 0 ;
for ( auto & i : lambda . formals - > formals ) {
2024-03-25 19:20:18 +02:00
auto j = args [ 0 ] - > attrs ( ) - > get ( i . name ) ;
2020-02-24 02:32:01 +02:00
if ( ! j ) {
2023-01-19 14:23:04 +02:00
if ( ! i . def ) {
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > ( " function '%1%' called without required argument '%2%' " ,
2023-01-19 14:23:04 +02:00
( lambda . name ? std : : string ( symbols [ lambda . name ] ) : " anonymous lambda " ) ,
symbols [ i . name ] )
. atPos ( lambda . pos )
. withTrace ( pos , " from call site " )
2024-03-25 19:20:18 +02:00
. withFrame ( * fun . payload . lambda . env , lambda )
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
. debugThrow ( ) ;
2023-01-19 14:23:04 +02:00
}
2020-02-24 02:32:01 +02:00
env2 . values [ displ + + ] = i . def - > maybeThunk ( * this , env2 ) ;
} else {
attrsUsed + + ;
env2 . values [ displ + + ] = j - > value ;
}
}
/* Check that each actual argument is listed as a formal
argument ( unless the attribute match specifies a ` . . . ' ) . */
2024-03-25 19:20:18 +02:00
if ( ! lambda . formals - > ellipsis & & attrsUsed ! = args [ 0 ] - > attrs ( ) - > size ( ) ) {
2020-02-24 02:32:01 +02:00
/* Nope, so show the first unexpected argument to the
user . */
2024-03-25 19:20:18 +02:00
for ( auto & i : * args [ 0 ] - > attrs ( ) )
2022-03-08 17:20:01 +02:00
if ( ! lambda . formals - > has ( i . name ) ) {
std : : set < std : : string > formalNames ;
for ( auto & formal : lambda . formals - > formals )
2024-06-06 17:33:41 +03:00
formalNames . insert ( std : : string ( symbols [ formal . name ] ) ) ;
2023-01-19 14:23:04 +02:00
auto suggestions = Suggestions : : bestMatches ( formalNames , symbols [ i . name ] ) ;
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > ( " function '%1%' called with unexpected argument '%2%' " ,
2023-01-19 14:23:04 +02:00
( lambda . name ? std : : string ( symbols [ lambda . name ] ) : " anonymous lambda " ) ,
symbols [ i . name ] )
. atPos ( lambda . pos )
. withTrace ( pos , " from call site " )
. withSuggestions ( suggestions )
2024-03-25 19:20:18 +02:00
. withFrame ( * fun . payload . lambda . env , lambda )
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
. debugThrow ( ) ;
2022-03-08 17:20:01 +02:00
}
2024-07-20 23:46:09 +03:00
unreachable ( ) ;
2020-02-24 02:32:01 +02:00
}
}
2010-04-14 17:42:32 +03:00
2020-02-24 02:32:01 +02:00
nrFunctionCalls + + ;
if ( countCalls ) incrFunctionCall ( & lambda ) ;
/* Evaluate the body. */
try {
2022-05-23 06:45:24 +03:00
auto dts = debugRepl
2022-05-05 13:29:14 +03:00
? makeDebugTraceStacker (
* this , * lambda . body , env2 , positions [ lambda . pos ] ,
2022-12-02 16:00:03 +02:00
" while calling %s " ,
2022-05-05 13:29:14 +03:00
lambda . name
? concatStrings ( " ' " , symbols [ lambda . name ] , " ' " )
: " anonymous lambda " )
: nullptr ;
2021-12-23 04:40:08 +02:00
2020-02-24 02:32:01 +02:00
lambda . body - > eval ( * this , env2 , vCur ) ;
} catch ( Error & e ) {
if ( loggerSettings . showTrace . get ( ) ) {
2023-01-19 14:23:04 +02:00
addErrorTrace (
e ,
lambda . pos ,
" while calling %s " ,
lambda . name
? concatStrings ( " ' " , symbols [ lambda . name ] , " ' " )
2024-02-23 03:14:55 +02:00
: " anonymous lambda " ) ;
2024-02-23 03:18:27 +02:00
if ( pos ) addErrorTrace ( e , pos , " from call site " ) ;
2020-02-24 02:32:01 +02:00
}
throw ;
}
nrArgs - - ;
args + = 1 ;
}
else if ( vCur . isPrimOp ( ) ) {
2024-03-25 19:20:18 +02:00
size_t argsLeft = vCur . primOp ( ) - > arity ;
2020-02-24 02:32:01 +02:00
if ( nrArgs < argsLeft ) {
/* We don't have enough arguments, so create a tPrimOpApp chain. */
makeAppChain ( ) ;
return ;
2021-08-25 22:18:27 +03:00
} else {
2020-02-24 02:32:01 +02:00
/* We have all the arguments, so call the primop. */
2024-03-25 19:20:18 +02:00
auto * fn = vCur . primOp ( ) ;
2023-01-19 14:23:04 +02:00
2020-02-24 02:32:01 +02:00
nrPrimOpCalls + + ;
2023-12-10 09:24:45 +02:00
if ( countCalls ) primOpCalls [ fn - > name ] + + ;
2023-01-19 14:23:04 +02:00
try {
2023-12-10 09:24:45 +02:00
fn - > fun ( * this , vCur . determinePos ( noPos ) , args , vCur ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
2024-03-24 01:04:30 +02:00
if ( fn - > addTrace )
addErrorTrace ( e , pos , " while calling the '%1%' builtin " , fn - > name ) ;
2023-01-19 14:23:04 +02:00
throw ;
}
2020-02-24 02:32:01 +02:00
nrArgs - = argsLeft ;
args + = argsLeft ;
2021-08-06 20:09:27 +03:00
}
}
2010-03-30 16:47:59 +03:00
2020-02-24 02:32:01 +02:00
else if ( vCur . isPrimOpApp ( ) ) {
/* Figure out the number of arguments still needed. */
size_t argsDone = 0 ;
Value * primOp = & vCur ;
while ( primOp - > isPrimOpApp ( ) ) {
argsDone + + ;
2024-03-25 19:20:18 +02:00
primOp = primOp - > payload . primOpApp . left ;
2020-02-24 02:32:01 +02:00
}
assert ( primOp - > isPrimOp ( ) ) ;
2024-03-25 19:20:18 +02:00
auto arity = primOp - > primOp ( ) - > arity ;
2020-02-24 02:32:01 +02:00
auto argsLeft = arity - argsDone ;
if ( nrArgs < argsLeft ) {
/* We still don't have enough arguments, so extend the tPrimOpApp chain. */
makeAppChain ( ) ;
return ;
} else {
/* We have all the arguments, so call the primop with
the previous and new arguments . */
2023-11-20 14:38:52 +02:00
Value * vArgs [ maxPrimOpArity ] ;
2020-02-24 02:32:01 +02:00
auto n = argsDone ;
2024-03-25 19:20:18 +02:00
for ( Value * arg = & vCur ; arg - > isPrimOpApp ( ) ; arg = arg - > payload . primOpApp . left )
vArgs [ - - n ] = arg - > payload . primOpApp . right ;
2020-02-24 02:32:01 +02:00
for ( size_t i = 0 ; i < argsLeft ; + + i )
vArgs [ argsDone + i ] = args [ i ] ;
2024-03-25 19:20:18 +02:00
auto fn = primOp - > primOp ( ) ;
2020-02-24 02:32:01 +02:00
nrPrimOpCalls + + ;
2023-12-10 09:24:45 +02:00
if ( countCalls ) primOpCalls [ fn - > name ] + + ;
2023-01-19 14:23:04 +02:00
try {
// TODO:
// 1. Unify this and above code. Heavily redundant.
// 2. Create a fake env (arg1, arg2, etc.) and a fake expr (arg1: arg2: etc: builtins.name arg1 arg2 etc)
// so the debugger allows to inspect the wrong parameters passed to the builtin.
2023-12-10 09:24:45 +02:00
fn - > fun ( * this , vCur . determinePos ( noPos ) , vArgs , vCur ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
2024-03-24 01:04:30 +02:00
if ( fn - > addTrace )
addErrorTrace ( e , pos , " while calling the '%1%' builtin " , fn - > name ) ;
2023-01-19 14:23:04 +02:00
throw ;
}
2020-02-24 02:32:01 +02:00
nrArgs - = argsLeft ;
args + = argsLeft ;
}
2013-05-16 18:56:14 +03:00
}
2021-08-25 22:18:27 +03:00
2024-03-25 19:20:18 +02:00
else if ( vCur . type ( ) = = nAttrs & & ( functor = vCur . attrs ( ) - > get ( sFunctor ) ) ) {
2021-11-16 23:34:17 +02:00
/* 'vCur' may be allocated on the stack of the calling
2021-11-16 18:44:19 +02:00
function , but for functors we may keep a reference , so
heap - allocate a copy and use that instead . */
2021-11-16 23:34:17 +02:00
Value * args2 [ ] = { allocValue ( ) , args [ 0 ] } ;
2021-11-16 18:44:19 +02:00
* args2 [ 0 ] = vCur ;
2023-01-19 14:23:04 +02:00
try {
callFunction ( * functor - > value , 2 , args2 , vCur , functor - > pos ) ;
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , " while calling a functor (an attribute set with a '__functor' attribute) " ) ;
throw ;
}
2021-11-16 23:34:17 +02:00
nrArgs - - ;
args + + ;
2013-05-16 18:56:14 +03:00
}
2020-02-24 02:32:01 +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
error < TypeError > (
" attempt to call something which is not a function but %1%: %2% " ,
2024-01-20 17:05:30 +02:00
showType ( vCur ) ,
ValuePrinter ( * this , vCur , errorPrintOptions ) )
. atPos ( pos )
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
. debugThrow ( ) ;
2010-03-30 16:47:59 +03:00
}
2020-02-24 02:32:01 +02:00
vRes = vCur ;
}
2013-11-12 13:51:59 +02:00
2020-02-24 02:32:01 +02:00
void ExprCall : : eval ( EvalState & state , Env & env , Value & v )
{
2024-02-03 05:14:22 +02:00
auto dts = state . debugRepl
? makeDebugTraceStacker (
state ,
* this ,
env ,
getPos ( )
? std : : make_shared < Pos > ( state . positions [ getPos ( ) ] )
: nullptr ,
" while calling a function "
)
: nullptr ;
2020-02-24 02:32:01 +02:00
Value vFun ;
fun - > eval ( state , env , vFun ) ;
2023-11-16 13:44:10 +02:00
// Empirical arity of Nixpkgs lambdas by regex e.g. ([a-zA-Z]+:(\s|(/\*.*\/)|(#.*\n))*){5}
// 2: over 4000
// 3: about 300
// 4: about 60
// 5: under 10
// This excluded attrset lambdas (`{...}:`). Contributions of mixed lambdas appears insignificant at ~150 total.
2023-11-20 14:38:52 +02:00
SmallValueVector < 4 > vArgs ( args . size ( ) ) ;
2020-02-24 02:32:01 +02:00
for ( size_t i = 0 ; i < args . size ( ) ; + + i )
vArgs [ i ] = args [ i ] - > maybeThunk ( state , env ) ;
2023-11-20 14:38:52 +02:00
state . callFunction ( vFun , args . size ( ) , vArgs . data ( ) , v , pos ) ;
2013-11-07 19:04:36 +02:00
}
// Lifted out of callFunction() because it creates a temporary that
// prevents tail-call optimisation.
void EvalState : : incrFunctionCall ( ExprLambda * fun )
{
functionCalls [ fun ] + + ;
2010-03-30 16:47:59 +03:00
}
2010-10-22 17:47:42 +03:00
void EvalState : : autoCallFunction ( Bindings & args , Value & fun , Value & res )
2010-04-07 18:47:06 +03:00
{
2022-02-04 01:31:33 +02:00
auto pos = fun . determinePos ( noPos ) ;
2021-11-27 19:40:24 +02:00
forceValue ( fun , pos ) ;
2010-04-07 18:47:06 +03:00
2020-12-17 15:45:45 +02:00
if ( fun . type ( ) = = nAttrs ) {
2024-03-25 19:20:18 +02:00
auto found = fun . attrs ( ) - > find ( sFunctor ) ;
if ( found ! = fun . attrs ( ) - > end ( ) ) {
2015-11-25 18:56:14 +02:00
Value * v = allocValue ( ) ;
2021-11-27 19:40:24 +02:00
callFunction ( * found - > value , fun , * v , pos ) ;
forceValue ( * v , pos ) ;
2015-11-25 18:56:14 +02:00
return autoCallFunction ( args , * v , res ) ;
}
}
2024-03-25 19:20:18 +02:00
if ( ! fun . isLambda ( ) | | ! fun . payload . lambda . fun - > hasFormals ( ) ) {
2010-04-07 18:47:06 +03:00
res = fun ;
return ;
}
2024-03-25 19:20:18 +02:00
auto attrs = buildBindings ( std : : max ( static_cast < uint32_t > ( fun . payload . lambda . fun - > formals - > formals . size ( ) ) , args . size ( ) ) ) ;
2010-04-12 21:30:11 +03:00
2024-03-25 19:20:18 +02:00
if ( fun . payload . lambda . fun - > formals - > ellipsis ) {
2020-08-27 19:28:12 +03:00
// If the formals have an ellipsis (eg the function accepts extra args) pass
// all available automatic arguments (which includes arguments specified on
// the command line via --arg/--argstr)
2022-01-04 18:39:16 +02:00
for ( auto & v : args )
attrs . insert ( v ) ;
2020-08-27 19:28:12 +03:00
} else {
// Otherwise, only pass the arguments that the function accepts
2024-03-25 19:20:18 +02:00
for ( auto & i : fun . payload . lambda . fun - > formals - > formals ) {
auto j = args . get ( i . name ) ;
if ( j ) {
2022-01-04 18:39:16 +02:00
attrs . insert ( * j ) ;
2020-08-27 19:28:12 +03:00
} else if ( ! i . def ) {
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 < MissingArgumentError > ( R " (cannot evaluate a function that has an argument without a value ('%1%')
2021-02-22 16:24:14 +02:00
Nix attempted to evaluate a function as a top level expression ; in
this case it must have its arguments supplied either by default
values , or passed explicitly with ' - - arg ' or ' - - argstr ' . See
2023-01-19 14:23:04 +02:00
https : //nixos.org/manual/nix/stable/language/constructs.html#functions.)", symbols[i.name])
2024-03-25 19:20:18 +02:00
. atPos ( i . pos ) . withFrame ( * fun . payload . lambda . env , * fun . payload . lambda . fun ) . debugThrow ( ) ;
2020-08-27 19:28:12 +03:00
}
}
2010-04-07 18:47:06 +03:00
}
2023-12-07 20:01:42 +02:00
callFunction ( fun , allocValue ( ) - > mkAttrs ( attrs ) , res , pos ) ;
2010-04-07 18:47:06 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprWith : : eval ( EvalState & state , Env & env , Value & v )
2010-03-29 17:37:56 +03:00
{
2010-04-14 18:01:04 +03:00
Env & env2 ( state . allocEnv ( 1 ) ) ;
2010-04-12 21:30:11 +03:00
env2 . up = & env ;
2023-12-22 19:19:53 +02:00
env2 . values [ 0 ] = attrs - > maybeThunk ( state , env ) ;
2021-11-09 22:14:49 +02:00
2012-02-04 15:50:25 +02:00
body - > eval ( state , env2 , v ) ;
2010-03-29 17:37:56 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprIf : : eval ( EvalState & state , Env & env , Value & v )
2010-03-29 17:37:56 +03:00
{
2023-01-19 14:23:04 +02:00
// We cheat in the parser, and pass the position of the condition as the position of the if itself.
( state . evalBool ( env , cond , pos , " while evaluating a branch condition " ) ? then : else_ ) - > eval ( state , env , v ) ;
2010-04-12 21:30:11 +03:00
}
2013-09-02 17:29:15 +03:00
2010-04-13 00:21:24 +03:00
void ExprAssert : : eval ( EvalState & state , Env & env , Value & v )
{
2023-01-19 14:23:04 +02:00
if ( ! state . evalBool ( env , cond , pos , " in the condition of the assert statement " ) ) {
2024-07-05 17:43:48 +03:00
auto exprStr = ( {
std : : ostringstream out ;
cond - > show ( state . symbols , out ) ;
out . str ( ) ;
} ) ;
if ( auto eq = dynamic_cast < ExprOpEq * > ( cond ) ) {
try {
Value v1 ; eq - > e1 - > eval ( state , env , v1 ) ;
Value v2 ; eq - > e2 - > eval ( state , env , v2 ) ;
state . assertEqValues ( v1 , v2 , eq - > pos , " in an equality assertion " ) ;
} catch ( AssertionError & e ) {
e . addTrace ( state . positions [ pos ] , " while evaluating the condition of the assertion '%s' " , exprStr ) ;
throw ;
}
}
state . error < AssertionError > ( " assertion '%1%' failed " , exprStr ) . atPos ( pos ) . withFrame ( env , * this ) . debugThrow ( ) ;
2020-01-11 16:06:57 +02:00
}
2012-02-04 15:50:25 +02:00
body - > eval ( state , env , v ) ;
2010-04-13 00:21:24 +03:00
}
2013-09-02 17:29:15 +03:00
2010-04-13 00:21:24 +03:00
void ExprOpNot : : eval ( EvalState & state , Env & env , Value & v )
{
2023-12-07 20:01:42 +02:00
v . mkBool ( ! state . evalBool ( env , e , getPos ( ) , " in the argument of the not operator " ) ) ; // XXX: FIXME: !
2010-04-13 00:21:24 +03:00
}
2010-04-12 21:30:11 +03:00
void ExprOpEq : : eval ( EvalState & state , Env & env , Value & v )
{
2012-02-04 15:50:25 +02:00
Value v1 ; e1 - > eval ( state , env , v1 ) ;
Value v2 ; e2 - > eval ( state , env , v2 ) ;
2023-01-19 14:23:04 +02:00
v . mkBool ( state . eqValues ( v1 , v2 , pos , " while testing two values for equality " ) ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpNEq : : eval ( EvalState & state , Env & env , Value & v )
{
2012-02-04 15:50:25 +02:00
Value v1 ; e1 - > eval ( state , env , v1 ) ;
Value v2 ; e2 - > eval ( state , env , v2 ) ;
2023-01-19 14:23:04 +02:00
v . mkBool ( ! state . eqValues ( v1 , v2 , pos , " while testing two values for inequality " ) ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpAnd : : eval ( EvalState & state , Env & env , Value & v )
{
2023-01-19 14:23:04 +02:00
v . mkBool ( state . evalBool ( env , e1 , pos , " in the left operand of the AND (&&) operator " ) & & state . evalBool ( env , e2 , pos , " in the right operand of the AND (&&) operator " ) ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpOr : : eval ( EvalState & state , Env & env , Value & v )
{
2023-01-19 14:23:04 +02:00
v . mkBool ( state . evalBool ( env , e1 , pos , " in the left operand of the OR (||) operator " ) | | state . evalBool ( env , e2 , pos , " in the right operand of the OR (||) operator " ) ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpImpl : : eval ( EvalState & state , Env & env , Value & v )
{
2023-01-19 14:23:04 +02:00
v . mkBool ( ! state . evalBool ( env , e1 , pos , " in the left operand of the IMPL (->) operator " ) | | state . evalBool ( env , e2 , pos , " in the right operand of the IMPL (->) operator " ) ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpUpdate : : eval ( EvalState & state , Env & env , Value & v )
{
2010-08-02 19:31:05 +03:00
Value v1 , v2 ;
2023-01-19 14:23:04 +02:00
state . evalAttrs ( env , e1 , v1 , pos , " in the left operand of the update (//) operator " ) ;
state . evalAttrs ( env , e2 , v2 , pos , " in the right operand of the update (//) operator " ) ;
2010-08-02 19:31:05 +03:00
2010-10-20 18:48:00 +03:00
state . nrOpUpdates + + ;
2024-03-25 19:20:18 +02:00
if ( v1 . attrs ( ) - > size ( ) = = 0 ) { v = v2 ; return ; }
if ( v2 . attrs ( ) - > size ( ) = = 0 ) { v = v1 ; return ; }
2010-08-02 19:31:05 +03:00
2024-03-25 19:20:18 +02:00
auto attrs = state . buildBindings ( v1 . attrs ( ) - > size ( ) + v2 . attrs ( ) - > size ( ) ) ;
2010-10-24 22:52:33 +03:00
2013-10-24 17:41:04 +03:00
/* Merge the sets, preferring values from the second set. Make
sure to keep the resulting vector in sorted order . */
2024-03-25 19:20:18 +02:00
auto i = v1 . attrs ( ) - > begin ( ) ;
auto j = v2 . attrs ( ) - > begin ( ) ;
2010-08-02 19:31:05 +03:00
2024-03-25 19:20:18 +02:00
while ( i ! = v1 . attrs ( ) - > end ( ) & & j ! = v2 . attrs ( ) - > end ( ) ) {
2010-10-24 22:52:33 +03:00
if ( i - > name = = j - > name ) {
2022-01-04 21:29:17 +02:00
attrs . insert ( * j ) ;
2010-10-24 22:52:33 +03:00
+ + i ; + + j ;
}
else if ( i - > name < j - > name )
2022-01-04 21:29:17 +02:00
attrs . insert ( * i + + ) ;
2010-10-24 22:52:33 +03:00
else
2022-01-04 21:29:17 +02:00
attrs . insert ( * j + + ) ;
2010-10-24 22:52:33 +03:00
}
2010-10-20 18:48:00 +03:00
2024-03-25 19:20:18 +02:00
while ( i ! = v1 . attrs ( ) - > end ( ) ) attrs . insert ( * i + + ) ;
while ( j ! = v2 . attrs ( ) - > end ( ) ) attrs . insert ( * j + + ) ;
2022-01-04 21:29:17 +02:00
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
2013-09-02 17:29:15 +03:00
2024-03-25 19:20:18 +02:00
state . nrOpUpdateValuesCopied + = v . attrs ( ) - > size ( ) ;
2010-04-12 21:30:11 +03:00
}
void ExprOpConcatLists : : eval ( EvalState & state , Env & env , Value & v )
{
2012-02-04 15:50:25 +02:00
Value v1 ; e1 - > eval ( state , env , v1 ) ;
Value v2 ; e2 - > eval ( state , env , v2 ) ;
2012-08-13 08:53:10 +03:00
Value * lists [ 2 ] = { & v1 , & v2 } ;
2023-01-19 14:23:04 +02:00
state . concatLists ( v , 2 , lists , pos , " while evaluating one of the elements to concatenate " ) ;
2012-08-13 08:53:10 +03:00
}
2024-03-15 19:22:39 +02:00
void EvalState : : concatLists ( Value & v , size_t nrLists , Value * const * lists , const PosIdx pos , std : : string_view errorCtx )
2012-08-13 08:53:10 +03:00
{
nrListConcats + + ;
2012-08-13 21:58:54 +03:00
Value * nonEmpty = 0 ;
2018-05-02 14:56:34 +03:00
size_t len = 0 ;
for ( size_t n = 0 ; n < nrLists ; + + n ) {
2023-01-19 14:23:04 +02:00
forceList ( * lists [ n ] , pos , errorCtx ) ;
2018-05-02 14:56:34 +03:00
auto l = lists [ n ] - > listSize ( ) ;
2012-08-13 21:58:54 +03:00
len + = l ;
if ( l ) nonEmpty = lists [ n ] ;
}
2015-07-23 23:05:09 +03:00
if ( nonEmpty & & len = = nonEmpty - > listSize ( ) ) {
2012-08-13 21:58:54 +03:00
v = * nonEmpty ;
return ;
2012-08-13 08:53:10 +03:00
}
2024-03-14 20:10:31 +02:00
auto list = buildList ( len ) ;
auto out = list . elems ;
2018-05-02 14:56:34 +03:00
for ( size_t n = 0 , pos = 0 ; n < nrLists ; + + n ) {
auto l = lists [ n ] - > listSize ( ) ;
2018-03-15 05:44:02 +02:00
if ( l )
memcpy ( out + pos , lists [ n ] - > listElems ( ) , l * sizeof ( Value * ) ) ;
2012-08-13 08:53:10 +03:00
pos + = l ;
}
2024-03-14 20:10:31 +02:00
v . mkList ( list ) ;
2010-03-29 17:37:56 +03:00
}
2010-04-13 00:21:24 +03:00
void ExprConcatStrings : : eval ( EvalState & state , Env & env , 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
NixStringContext context ;
2022-01-21 17:20:54 +02:00
std : : vector < BackedStringView > s ;
2021-12-27 03:04:49 +02:00
size_t sSize = 0 ;
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
NixInt n { 0 } ;
2016-01-05 01:40:40 +02:00
NixFloat nf = 0 ;
2013-08-02 18:21:17 +03:00
2013-10-17 01:39:59 +03:00
bool first = ! forceString ;
2020-12-17 15:42:52 +02:00
ValueType firstType = nString ;
2010-04-13 00:21:24 +03:00
2021-12-27 03:04:49 +02:00
const auto str = [ & ] {
std : : string result ;
result . reserve ( sSize ) ;
2022-01-21 17:20:54 +02:00
for ( const auto & part : s ) result + = * part ;
2021-12-27 03:04:49 +02:00
return result ;
} ;
/* c_str() is not str().c_str() because we want to create a string
Value . allocating a GC ' d string directly and moving it into a
Value lets us avoid an allocation and copy . */
const auto c_str = [ & ] {
char * result = allocString ( sSize + 1 ) ;
char * tmp = result ;
for ( const auto & part : s ) {
2022-01-21 17:20:54 +02:00
memcpy ( tmp , part - > data ( ) , part - > size ( ) ) ;
tmp + = part - > size ( ) ;
2021-12-27 03:04:49 +02:00
}
* tmp = 0 ;
return result ;
} ;
2023-11-20 14:38:52 +02:00
// List of returned strings. References to these Values must NOT be persisted.
SmallTemporaryValueVector < conservativeStackReservation > values ( es - > size ( ) ) ;
Value * vTmpP = values . data ( ) ;
2022-01-21 17:20:54 +02:00
2021-09-23 05:30:31 +03:00
for ( auto & [ i_pos , i ] : * es ) {
2022-01-21 17:20:54 +02:00
Value & vTmp = * vTmpP + + ;
2015-07-17 20:24:28 +03:00
i - > eval ( state , env , vTmp ) ;
2010-04-13 00:21:24 +03:00
/* If the first element is a path, then the result will also
be a path , we don ' t copy anything ( yet - that ' s done later ,
since paths are copied when they are used in a derivation ) ,
and none of the strings are allowed to have contexts . */
if ( first ) {
2020-12-17 15:45:45 +02:00
firstType = vTmp . type ( ) ;
2010-04-13 00:21:24 +03:00
}
2012-08-13 22:10:29 +03:00
2020-12-12 03:09:10 +02:00
if ( firstType = = nInt ) {
2020-12-17 15:45:45 +02:00
if ( vTmp . type ( ) = = nInt ) {
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
auto newN = n + vTmp . integer ( ) ;
if ( auto checked = newN . valueChecked ( ) ; checked . has_value ( ) ) {
n = NixInt ( * checked ) ;
} else {
state . error < EvalError > ( " integer overflow in adding %1% + %2% " , n , vTmp . integer ( ) ) . atPos ( i_pos ) . debugThrow ( ) ;
}
2020-12-17 15:45:45 +02:00
} else if ( vTmp . type ( ) = = nFloat ) {
2016-01-05 01:40:40 +02:00
// Upgrade the type from int to float;
2020-12-12 03:09:10 +02:00
firstType = nFloat ;
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
nf = n . value ;
2024-03-25 19:20:18 +02:00
nf + = vTmp . fpoint ( ) ;
2016-01-05 01:40:40 +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 > ( " cannot add %1% to an integer " , showType ( vTmp ) ) . atPos ( i_pos ) . withFrame ( env , * this ) . debugThrow ( ) ;
2020-12-12 03:09:10 +02:00
} else if ( firstType = = nFloat ) {
2020-12-17 15:45:45 +02:00
if ( vTmp . type ( ) = = nInt ) {
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
nf + = vTmp . integer ( ) . value ;
2020-12-17 15:45:45 +02:00
} else if ( vTmp . type ( ) = = nFloat ) {
2024-03-25 19:20:18 +02:00
nf + = vTmp . fpoint ( ) ;
2016-01-05 01:40:40 +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 > ( " cannot add %1% to a float " , showType ( vTmp ) ) . atPos ( i_pos ) . withFrame ( env , * this ) . debugThrow ( ) ;
2021-12-27 03:04:49 +02:00
} else {
if ( s . empty ( ) ) s . reserve ( es - > size ( ) ) ;
2021-07-29 19:03:07 +03:00
/* skip canonization of first path, which would only be not
canonized in the first place if it ' s coming from a . / $ { foo } type
path */
2022-11-29 01:25:36 +02:00
auto part = state . coerceToString ( i_pos , vTmp , context ,
" while evaluating a path segment " ,
false , firstType = = nString , ! first ) ;
2022-01-21 17:20:54 +02:00
sSize + = part - > size ( ) ;
s . emplace_back ( std : : move ( part ) ) ;
2021-12-27 03:04:49 +02:00
}
2021-07-29 19:03:07 +03:00
first = false ;
2010-04-13 00:21:24 +03:00
}
2020-12-12 03:09:10 +02:00
if ( firstType = = nInt )
2022-01-04 19:40:39 +02:00
v . mkInt ( n ) ;
2020-12-12 03:09:10 +02:00
else if ( firstType = = nFloat )
2022-01-04 19:40:39 +02:00
v . mkFloat ( nf ) ;
2020-12-12 03:09:10 +02:00
else if ( firstType = = nPath ) {
2013-08-02 18:21:17 +03:00
if ( ! context . 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 > ( " a string that refers to a store path cannot be appended to a path " ) . atPos ( pos ) . withFrame ( env , * this ) . debugThrow ( ) ;
2023-10-18 16:32:31 +03:00
v . mkPath ( state . rootPath ( CanonPath ( canonPath ( str ( ) ) ) ) ) ;
2013-08-02 18:21:17 +03:00
} else
2021-12-27 03:04:49 +02:00
v . mkStringMove ( c_str ( ) , context ) ;
2010-04-13 00:21:24 +03:00
}
2013-11-18 21:14:54 +02:00
void ExprPos : : eval ( EvalState & state , Env & env , Value & v )
{
2022-03-04 20:31:59 +02:00
state . mkPos ( v , pos ) ;
2013-11-18 21:14:54 +02:00
}
2023-12-11 17:23:08 +02:00
void ExprBlackHole : : eval ( EvalState & state , Env & env , Value & v )
{
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 < InfiniteRecursionError > ( " infinite recursion encountered " )
. atPos ( v . determinePos ( noPos ) )
. debugThrow ( ) ;
2023-12-11 17:23:08 +02:00
}
// always force this to be separate, otherwise forceValue may inline it and take
// a massive perf hit
[[gnu::noinline]]
void EvalState : : tryFixupBlackHolePos ( Value & v , PosIdx pos )
{
if ( ! v . isBlackhole ( ) )
return ;
auto e = std : : current_exception ( ) ;
try {
std : : rethrow_exception ( e ) ;
} catch ( InfiniteRecursionError & 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
e . atPos ( positions [ pos ] ) ;
2023-12-11 17:23:08 +02:00
} catch ( . . . ) {
}
}
2014-09-22 16:03:59 +03:00
void EvalState : : forceValueDeep ( Value & v )
2010-04-07 16:55:46 +03:00
{
2014-09-22 16:16:09 +03:00
std : : set < const Value * > seen ;
2013-09-02 17:29:15 +03:00
2014-09-22 16:16:09 +03:00
std : : function < void ( Value & v ) > recurse ;
2013-09-02 17:29:15 +03:00
2014-09-22 16:16:09 +03:00
recurse = [ & ] ( Value & v ) {
2019-10-09 16:51:52 +03:00
if ( ! seen . insert ( & v ) . second ) return ;
2014-09-22 16:16:09 +03:00
2023-12-11 16:48:24 +02:00
forceValue ( v , v . determinePos ( noPos ) ) ;
2014-09-22 16:16:09 +03:00
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nAttrs ) {
2024-03-25 19:20:18 +02:00
for ( auto & i : * v . attrs ( ) )
2015-03-06 16:10:12 +02:00
try {
2022-05-05 13:29:14 +03:00
// If the value is a thunk, we're evaling. Otherwise no trace necessary.
2022-05-23 06:45:24 +03:00
auto dts = debugRepl & & i . value - > isThunk ( )
2024-03-25 19:20:18 +02:00
? makeDebugTraceStacker ( * this , * i . value - > payload . thunk . expr , * i . value - > payload . thunk . env , positions [ i . pos ] ,
2022-05-05 13:29:14 +03:00
" while evaluating the attribute '%1%' " , symbols [ i . name ] )
2022-04-09 00:46:12 +03:00
: nullptr ;
2021-12-23 04:40:08 +02:00
2015-03-06 16:10:12 +02:00
recurse ( * i . value ) ;
} catch ( Error & e ) {
2022-03-05 15:40:24 +02:00
addErrorTrace ( e , i . pos , " while evaluating the attribute '%1%' " , symbols [ i . name ] ) ;
2015-03-06 16:10:12 +02:00
throw ;
}
2014-09-22 16:16:09 +03:00
}
2015-07-23 23:05:09 +03:00
else if ( v . isList ( ) ) {
2021-11-24 21:21:34 +02:00
for ( auto v2 : v . listItems ( ) )
recurse ( * v2 ) ;
2014-09-22 16:16:09 +03:00
}
} ;
recurse ( v ) ;
2010-04-07 16:55:46 +03:00
}
2023-01-19 14:23:04 +02:00
NixInt EvalState : : forceInt ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2010-03-29 17:37:56 +03:00
{
2023-01-19 14:23:04 +02:00
try {
forceValue ( v , pos ) ;
if ( v . type ( ) ! = nInt )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected an integer but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . debugThrow ( ) ;
2024-03-25 19:20:18 +02:00
return v . integer ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
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
2024-03-25 19:20:18 +02:00
return v . integer ( ) ;
2010-03-29 17:37:56 +03:00
}
2023-01-19 14:23:04 +02:00
NixFloat EvalState : : forceFloat ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2016-01-05 01:40:40 +02:00
{
2023-01-19 14:23:04 +02:00
try {
forceValue ( v , pos ) ;
if ( v . type ( ) = = nInt )
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
return v . integer ( ) . value ;
2023-01-19 14:23:04 +02:00
else if ( v . type ( ) ! = nFloat )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a float but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . debugThrow ( ) ;
2024-03-25 19:20:18 +02:00
return v . fpoint ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2016-01-05 01:40:40 +02:00
}
2023-01-19 14:23:04 +02:00
bool EvalState : : forceBool ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2010-03-31 18:38:03 +03:00
{
2023-01-19 14:23:04 +02:00
try {
forceValue ( v , pos ) ;
if ( v . type ( ) ! = nBool )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a Boolean but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . debugThrow ( ) ;
2024-03-25 19:20:18 +02:00
return v . boolean ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
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
2024-03-25 19:20:18 +02:00
return v . boolean ( ) ;
2010-03-31 18:38:03 +03:00
}
2015-10-08 14:22:11 +03:00
bool EvalState : : isFunctor ( Value & fun )
{
2024-03-25 19:20:18 +02:00
return fun . type ( ) = = nAttrs & & fun . attrs ( ) - > find ( sFunctor ) ! = fun . attrs ( ) - > end ( ) ;
2015-10-08 14:22:11 +03:00
}
2023-01-19 14:23:04 +02:00
void EvalState : : forceFunction ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2010-03-30 16:47:59 +03:00
{
2023-01-19 14:23:04 +02:00
try {
forceValue ( v , pos ) ;
if ( v . type ( ) ! = nFunction & & ! isFunctor ( v ) )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a function but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . debugThrow ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2010-03-30 16:47:59 +03:00
}
2023-01-19 14:23:04 +02:00
std : : string_view EvalState : : forceString ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2010-03-30 21:05:54 +03:00
{
2023-01-19 14:23:04 +02:00
try {
forceValue ( v , pos ) ;
if ( v . type ( ) ! = nString )
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > (
" expected a string but found %1%: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
) . atPos ( pos ) . debugThrow ( ) ;
2023-09-26 04:30:41 +03:00
return v . string_view ( ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
2014-04-04 22:14:11 +03:00
}
2010-03-31 18:38:03 +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
void copyContext ( const Value & v , NixStringContext & context )
2010-03-31 22:52:29 +03:00
{
2024-03-25 19:20:18 +02:00
if ( v . payload . string . context )
for ( const char * * p = v . payload . string . context ; * p ; + + p )
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 : : parse ( * p ) ) ;
2010-06-10 13:29:50 +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
std : : string_view EvalState : : forceString ( Value & v , NixStringContext & context , const PosIdx pos , std : : string_view errorCtx )
2010-06-10 13:29:50 +03:00
{
2023-01-19 14:23:04 +02:00
auto s = forceString ( v , pos , errorCtx ) ;
2010-06-10 13:29:50 +03:00
copyContext ( v , context ) ;
2010-03-31 22:52:29 +03:00
return s ;
}
2023-01-19 14:23:04 +02:00
std : : string_view EvalState : : forceStringNoCtx ( Value & v , const PosIdx pos , std : : string_view errorCtx )
2010-03-31 18:38:03 +03:00
{
2023-01-19 14:23:04 +02:00
auto s = forceString ( v , pos , errorCtx ) ;
2023-09-26 04:30:41 +03:00
if ( v . context ( ) ) {
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 < EvalError > ( " the string '%1%' is not allowed to refer to a store path (such as '%2%') " , v . string_view ( ) , v . context ( ) [ 0 ] ) . withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2014-04-04 22:14:11 +03:00
}
2010-03-31 18:38:03 +03:00
return s ;
2010-03-30 21:05:54 +03:00
}
2010-04-07 16:55:46 +03:00
bool EvalState : : isDerivation ( Value & v )
{
2020-12-17 15:45:45 +02:00
if ( v . type ( ) ! = nAttrs ) return false ;
2024-03-25 19:20:18 +02:00
auto i = v . attrs ( ) - > get ( sType ) ;
if ( ! i ) return false ;
2022-03-04 20:31:59 +02:00
forceValue ( * i - > value , i - > pos ) ;
2020-12-17 15:45:45 +02:00
if ( i - > value - > type ( ) ! = nString ) return false ;
2023-09-26 04:30:41 +03:00
return i - > value - > string_view ( ) . compare ( " derivation " ) = = 0 ;
2010-04-07 16:55:46 +03:00
}
2022-03-04 20:31:59 +02:00
std : : optional < std : : string > EvalState : : tryAttrsToString ( const PosIdx pos , 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
NixStringContext & context , bool coerceMore , bool copyToStore )
2019-10-27 11:15:51 +02:00
{
2024-03-25 19:20:18 +02:00
auto i = v . attrs ( ) - > find ( sToString ) ;
if ( i ! = v . attrs ( ) - > end ( ) ) {
2019-10-27 11:15:51 +02:00
Value v1 ;
callFunction ( * i - > value , v , v1 , pos ) ;
2022-11-29 01:25:36 +02:00
return coerceToString ( pos , v1 , context ,
2023-01-20 14:06:00 +02:00
" while evaluating the result of the `__toString` attribute " ,
2022-11-29 01:25:36 +02:00
coerceMore , copyToStore ) . toOwned ( ) ;
2019-10-27 11:15:51 +02:00
}
return { } ;
}
2023-04-06 14:15:50 +03:00
BackedStringView EvalState : : coerceToString (
const PosIdx pos ,
Value & v ,
2023-04-24 14:20:36 +03:00
NixStringContext & context ,
2023-04-06 14:15:50 +03:00
std : : string_view errorCtx ,
bool coerceMore ,
bool copyToStore ,
bool canonicalizePath )
2010-03-30 12:22:33 +03:00
{
2020-04-16 13:32:07 +03:00
forceValue ( v , pos ) ;
2010-03-30 12:22:33 +03:00
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nString ) {
2010-06-10 13:29:50 +03:00
copyContext ( v , context ) ;
2023-09-26 04:30:41 +03:00
return v . string_view ( ) ;
2010-03-31 22:52:29 +03:00
}
2010-03-30 12:22:33 +03:00
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nPath ) {
2023-04-06 14:15:50 +03:00
return
! canonicalizePath & & ! copyToStore
? // FIXME: hack to preserve path literals that end in a
// slash, as in /foo/${x}.
2024-03-25 19:20:18 +02:00
v . payload . path . path
2023-04-06 14:15:50 +03:00
: copyToStore
? store - > printStorePath ( copyPathToStore ( context , v . path ( ) ) )
: std : : string ( v . path ( ) . path . abs ( ) ) ;
2010-03-30 12:22:33 +03:00
}
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nAttrs ) {
2019-10-27 11:15:51 +02:00
auto maybeString = tryAttrsToString ( pos , v , context , coerceMore , copyToStore ) ;
2022-01-21 17:20:54 +02:00
if ( maybeString )
return std : : move ( * maybeString ) ;
2024-03-25 19:20:18 +02:00
auto i = v . attrs ( ) - > find ( sOutPath ) ;
if ( i = = v . attrs ( ) - > 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
error < TypeError > (
" cannot coerce %1% to a string: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
)
2022-11-29 01:25:36 +02:00
. withTrace ( pos , errorCtx )
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
. debugThrow ( ) ;
2022-11-29 01:25:36 +02:00
}
return coerceToString ( pos , * i - > value , context , errorCtx ,
coerceMore , copyToStore , canonicalizePath ) ;
2010-03-30 12:22:33 +03:00
}
2022-11-29 01:25:36 +02:00
if ( v . type ( ) = = nExternal ) {
try {
2024-03-25 19:20:18 +02:00
return v . external ( ) - > coerceToString ( * this , pos , context , coerceMore , copyToStore ) ;
2022-11-29 01:25:36 +02:00
} catch ( Error & e ) {
e . addTrace ( nullptr , errorCtx ) ;
throw ;
}
}
2014-11-30 20:16:19 +02:00
2010-03-30 12:22:33 +03:00
if ( coerceMore ) {
/* Note that `false' is represented as an empty string for
shell scripting convenience , just like ` null ' . */
2024-03-25 19:20:18 +02:00
if ( v . type ( ) = = nBool & & v . boolean ( ) ) return " 1 " ;
if ( v . type ( ) = = nBool & & ! v . boolean ( ) ) return " " ;
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
if ( v . type ( ) = = nInt ) return std : : to_string ( v . integer ( ) . value ) ;
2024-03-25 19:20:18 +02:00
if ( v . type ( ) = = nFloat ) return std : : to_string ( v . fpoint ( ) ) ;
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nNull ) return " " ;
2010-03-30 12:22:33 +03:00
2015-07-23 23:05:09 +03:00
if ( v . isList ( ) ) {
2022-02-25 17:00:00 +02:00
std : : string result ;
2021-11-24 21:21:34 +02:00
for ( auto [ n , v2 ] : enumerate ( v . listItems ( ) ) ) {
2023-01-19 14:23:04 +02:00
try {
2023-12-07 20:01:42 +02:00
result + = * coerceToString ( pos , * v2 , context ,
2022-11-29 01:25:36 +02:00
" while evaluating one element of the list " ,
coerceMore , copyToStore , canonicalizePath ) ;
2023-01-19 14:23:04 +02:00
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2015-07-23 23:05:09 +03:00
if ( n < v . listSize ( ) - 1
2010-04-01 17:35:03 +03:00
/* !!! not quite correct */
2021-11-24 21:21:34 +02:00
& & ( ! v2 - > isList ( ) | | v2 - > listSize ( ) ! = 0 ) )
2010-04-01 17:35:03 +03:00
result + = " " ;
2010-03-30 12:22:33 +03:00
}
2023-10-16 23:48:02 +03:00
return result ;
2010-03-30 12:22:33 +03:00
}
}
2013-09-02 17:29:15 +03:00
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < TypeError > ( " cannot coerce %1% to a string: %2% " ,
showType ( v ) ,
ValuePrinter ( * this , v , errorPrintOptions )
)
2022-11-29 01:25:36 +02:00
. withTrace ( pos , errorCtx )
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
. debugThrow ( ) ;
2010-03-30 12:22:33 +03:00
}
2023-04-24 14:20:36 +03:00
StorePath EvalState : : copyPathToStore ( NixStringContext & context , const SourcePath & path )
2013-11-19 01:03:11 +02:00
{
2023-04-06 14:15:50 +03:00
if ( nix : : isDerivation ( path . 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
error < EvalError > ( " file names are not allowed to end in '%1%' " , drvExtension ) . debugThrow ( ) ;
2013-11-19 01:03:11 +02:00
2024-06-04 17:05:56 +03:00
auto dstPathCached = get ( * srcToStore . lock ( ) , path ) ;
2023-04-06 14:15:50 +03:00
2024-06-04 17:05:56 +03:00
auto dstPath = dstPathCached
? * dstPathCached
2023-04-06 14:15:50 +03:00
: [ & ] ( ) {
2024-02-20 11:36:36 +02:00
auto dstPath = fetchToStore (
* store ,
path . resolveSymlinks ( ) ,
settings . readOnlyMode ? FetchMode : : DryRun : FetchMode : : Copy ,
path . baseName ( ) ,
2024-05-17 02:08:28 +03:00
ContentAddressMethod : : Raw : : NixArchive ,
2024-02-20 11:36:36 +02:00
nullptr ,
repair ) ;
2023-04-06 14:15:50 +03:00
allowPath ( dstPath ) ;
2024-06-04 17:05:56 +03:00
srcToStore . lock ( ) - > try_emplace ( path , dstPath ) ;
2023-04-06 14:15:50 +03:00
printMsg ( lvlChatty , " copied source '%1%' -> '%2%' " , path , store - > printStorePath ( dstPath ) ) ;
return dstPath ;
} ( ) ;
2013-11-19 01:03:11 +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
context . insert ( NixStringContextElem : : Opaque {
. path = dstPath
} ) ;
2013-11-19 01:03:11 +02:00
return dstPath ;
}
2023-04-24 14:20:36 +03:00
SourcePath EvalState : : coerceToPath ( const PosIdx pos , Value & v , NixStringContext & context , std : : string_view errorCtx )
2010-03-30 12:22:33 +03:00
{
2023-10-18 18:34:58 +03:00
try {
forceValue ( v , pos ) ;
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , errorCtx ) ;
throw ;
}
2023-10-20 14:04:39 +03:00
/* Handle path values directly, without coercing to a string. */
2023-10-18 18:34:58 +03:00
if ( v . type ( ) = = nPath )
return v . path ( ) ;
2023-10-20 14:04:39 +03:00
/* Similarly, handle __toString where the result may be a path
value . */
2023-10-18 18:34:58 +03:00
if ( v . type ( ) = = nAttrs ) {
2024-03-25 19:20:18 +02:00
auto i = v . attrs ( ) - > find ( sToString ) ;
if ( i ! = v . attrs ( ) - > end ( ) ) {
2023-10-20 14:04:39 +03:00
Value v1 ;
callFunction ( * i - > value , v , v1 , pos ) ;
return coerceToPath ( pos , v1 , context , errorCtx ) ;
}
2023-10-18 18:34:58 +03:00
}
2023-10-20 14:04:39 +03:00
/* Any other value should be coercable to a string, interpreted
relative to the root filesystem . */
auto path = coerceToString ( pos , v , context , errorCtx , false , false , true ) . toOwned ( ) ;
if ( path = = " " | | path [ 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
error < EvalError > ( " string '%1%' doesn't represent an absolute path " , path ) . withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2023-10-20 14:04:39 +03:00
return rootPath ( CanonPath ( path ) ) ;
2010-03-30 12:22:33 +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
StorePath EvalState : : coerceToStorePath ( const PosIdx pos , Value & v , NixStringContext & context , std : : string_view errorCtx )
2022-03-02 11:57:19 +02:00
{
2022-11-29 01:25:36 +02:00
auto path = coerceToString ( pos , v , context , errorCtx , false , false , true ) . toOwned ( ) ;
2022-03-02 11:57:19 +02:00
if ( auto storePath = store - > maybeParseStorePath ( path ) )
return * storePath ;
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 < EvalError > ( " path '%1%' is not in the Nix store " , path ) . withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2022-03-02 11:57:19 +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
std : : pair < SingleDerivedPath , std : : string_view > EvalState : : coerceToSingleDerivedPathUnchecked ( const PosIdx pos , Value & v , std : : string_view errorCtx )
2023-05-11 02:25:52 +03:00
{
NixStringContext context ;
auto s = forceString ( v , context , pos , errorCtx ) ;
auto csize = context . size ( ) ;
if ( csize ! = 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
error < EvalError > (
2023-05-11 02:25:52 +03:00
" string '%s' has %d entries in its context. It should only have exactly one entry " ,
s , csize )
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
. withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2023-05-11 02:25:52 +03:00
auto derivedPath = std : : visit ( overloaded {
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
[ & ] ( NixStringContextElem : : Opaque & & o ) - > SingleDerivedPath {
return std : : move ( o ) ;
2023-05-11 02:25:52 +03: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
[ & ] ( NixStringContextElem : : DrvDeep & & ) - > SingleDerivedPath {
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 < EvalError > (
2023-05-11 02:25:52 +03:00
" string '%s' has a context which refers to a complete source and binary closure. This is not supported at this time " ,
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
s ) . withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2023-05-11 02:25:52 +03: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
[ & ] ( NixStringContextElem : : Built & & b ) - > SingleDerivedPath {
return std : : move ( b ) ;
2023-05-11 02:25:52 +03:00
} ,
2023-08-16 19:29:23 +03:00
} , ( ( NixStringContextElem & & ) * context . begin ( ) ) . raw ) ;
2023-05-11 02:25:52 +03:00
return {
std : : move ( derivedPath ) ,
std : : move ( s ) ,
} ;
}
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
SingleDerivedPath EvalState : : coerceToSingleDerivedPath ( const PosIdx pos , Value & v , std : : string_view errorCtx )
2023-05-11 02:25:52 +03: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
auto [ derivedPath , s_ ] = coerceToSingleDerivedPathUnchecked ( pos , v , errorCtx ) ;
2023-05-11 02:25:52 +03:00
auto s = s_ ;
2021-03-10 06:22:56 +02:00
auto sExpected = mkSingleDerivedPathStringRaw ( derivedPath ) ;
if ( s ! = sExpected ) {
/* `std::visit` is used here just to provide a more precise
error message . */
std : : visit ( overloaded {
[ & ] ( const SingleDerivedPath : : Opaque & o ) {
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 < EvalError > (
2023-05-11 02:25:52 +03:00
" path string '%s' has context with the different path '%s' " ,
s , sExpected )
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
. withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2021-03-10 06:22:56 +02:00
} ,
[ & ] ( const SingleDerivedPath : : Built & b ) {
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 < EvalError > (
2023-05-11 02:25:52 +03:00
" string '%s' has context with the output '%s' from derivation '%s', but the string is not the right placeholder for this derivation output. It should be '%s' " ,
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
s , b . output , b . drvPath - > to_string ( * store ) , sExpected )
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
. withTrace ( pos , errorCtx ) . debugThrow ( ) ;
2021-03-10 06:22:56 +02:00
}
} , derivedPath . raw ( ) ) ;
}
2023-05-11 02:25:52 +03:00
return derivedPath ;
}
2024-07-05 17:43:48 +03:00
// NOTE: This implementation must match eqValues!
// We accept this burden because informative error messages for
// `assert a == b; x` are critical for our users' testing UX.
void EvalState : : assertEqValues ( Value & v1 , Value & v2 , const PosIdx pos , std : : string_view errorCtx )
{
// This implementation must match eqValues.
forceValue ( v1 , pos ) ;
forceValue ( v2 , pos ) ;
if ( & v1 = = & v2 )
return ;
// Special case type-compatibility between float and int
if ( ( v1 . type ( ) = = nInt | | v1 . type ( ) = = nFloat ) & & ( v2 . type ( ) = = nInt | | v2 . type ( ) = = nFloat ) ) {
if ( eqValues ( v1 , v2 , pos , errorCtx ) ) {
return ;
} else {
error < AssertionError > (
" %s with value '%s' is not equal to %s with value '%s' " ,
showType ( v1 ) ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
showType ( v2 ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
}
if ( v1 . type ( ) ! = v2 . type ( ) ) {
error < AssertionError > (
" %s of value '%s' is not equal to %s of value '%s' " ,
showType ( v1 ) ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
showType ( v2 ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
switch ( v1 . type ( ) ) {
case nInt :
if ( v1 . integer ( ) ! = v2 . integer ( ) ) {
error < AssertionError > ( " integer '%d' is not equal to integer '%d' " , v1 . integer ( ) , v2 . integer ( ) ) . debugThrow ( ) ;
}
return ;
case nBool :
if ( v1 . boolean ( ) ! = v2 . boolean ( ) ) {
error < AssertionError > (
" boolean '%s' is not equal to boolean '%s' " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
return ;
case nString :
if ( strcmp ( v1 . c_str ( ) , v2 . c_str ( ) ) ! = 0 ) {
error < AssertionError > (
" string '%s' is not equal to string '%s' " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
return ;
case nPath :
if ( v1 . payload . path . accessor ! = v2 . payload . path . accessor ) {
error < AssertionError > (
" path '%s' is not equal to path '%s' because their accessors are different " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
if ( strcmp ( v1 . payload . path . path , v2 . payload . path . path ) ! = 0 ) {
error < AssertionError > (
" path '%s' is not equal to path '%s' " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
return ;
case nNull :
return ;
case nList :
if ( v1 . listSize ( ) ! = v2 . listSize ( ) ) {
error < AssertionError > (
" list of size '%d' is not equal to list of size '%d', left hand side is '%s', right hand side is '%s' " ,
v1 . listSize ( ) ,
v2 . listSize ( ) ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
for ( size_t n = 0 ; n < v1 . listSize ( ) ; + + n ) {
try {
assertEqValues ( * v1 . listElems ( ) [ n ] , * v2 . listElems ( ) [ n ] , pos , errorCtx ) ;
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , " while comparing list element %d " , n ) ;
throw ;
}
}
return ;
case nAttrs : {
if ( isDerivation ( v1 ) & & isDerivation ( v2 ) ) {
auto i = v1 . attrs ( ) - > get ( sOutPath ) ;
auto j = v2 . attrs ( ) - > get ( sOutPath ) ;
if ( i & & j ) {
try {
assertEqValues ( * i - > value , * j - > value , pos , errorCtx ) ;
return ;
} catch ( Error & e ) {
e . addTrace ( positions [ pos ] , " while comparing a derivation by its '%s' attribute " , " outPath " ) ;
throw ;
}
assert ( false ) ;
}
}
if ( v1 . attrs ( ) - > size ( ) ! = v2 . attrs ( ) - > size ( ) ) {
error < AssertionError > (
" attribute names of attribute set '%s' differs from attribute set '%s' " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
// Like normal comparison, we compare the attributes in non-deterministic Symbol index order.
// This function is called when eqValues has found a difference, so to reliably
// report about its result, we should follow in its literal footsteps and not
// try anything fancy that could lead to an error.
Bindings : : const_iterator i , j ;
for ( i = v1 . attrs ( ) - > begin ( ) , j = v2 . attrs ( ) - > begin ( ) ; i ! = v1 . attrs ( ) - > end ( ) ; + + i , + + j ) {
if ( i - > name ! = j - > name ) {
// A difference in a sorted list means that one attribute is not contained in the other, but we don't
// know which. Let's find out. Could use <, but this is more clear.
if ( ! v2 . attrs ( ) - > get ( i - > name ) ) {
error < AssertionError > (
" attribute name '%s' is contained in '%s', but not in '%s' " ,
symbols [ i - > name ] ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
if ( ! v1 . attrs ( ) - > get ( j - > name ) ) {
error < AssertionError > (
" attribute name '%s' is missing in '%s', but is contained in '%s' " ,
symbols [ j - > name ] ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
assert ( false ) ;
}
try {
assertEqValues ( * i - > value , * j - > value , pos , errorCtx ) ;
} catch ( Error & e ) {
// The order of traces is reversed, so this presents as
// where left hand side is
// at <pos>
// where right hand side is
// at <pos>
// while comparing attribute '<name>'
if ( j - > pos ! = noPos )
e . addTrace ( positions [ j - > pos ] , " where right hand side is " ) ;
if ( i - > pos ! = noPos )
e . addTrace ( positions [ i - > pos ] , " where left hand side is " ) ;
e . addTrace ( positions [ pos ] , " while comparing attribute '%s' " , symbols [ i - > name ] ) ;
throw ;
}
}
return ;
}
case nFunction :
error < AssertionError > ( " distinct functions and immediate comparisons of identical functions compare as unequal " )
. debugThrow ( ) ;
case nExternal :
if ( ! ( * v1 . external ( ) = = * v2 . external ( ) ) ) {
error < AssertionError > (
" external value '%s' is not equal to external value '%s' " ,
ValuePrinter ( * this , v1 , errorPrintOptions ) ,
ValuePrinter ( * this , v2 , errorPrintOptions ) )
. debugThrow ( ) ;
}
return ;
case nFloat :
// !!!
if ( ! ( v1 . fpoint ( ) = = v2 . fpoint ( ) ) ) {
error < AssertionError > ( " float '%f' is not equal to float '%f' " , v1 . fpoint ( ) , v2 . fpoint ( ) ) . debugThrow ( ) ;
}
return ;
case nThunk : // Must not be left by forceValue
2024-07-11 12:37:45 +03:00
assert ( false ) ;
default : // Note that we pass compiler flags that should make `default:` unreachable.
// Also note that this probably ran after `eqValues`, which implements
// the same logic more efficiently (without having to unwind stacks),
// so maybe `assertEqValues` and `eqValues` are out of sync. Check it for solutions.
error < EvalError > ( " assertEqValues: cannot compare %1% with %2% " , showType ( v1 ) , showType ( v2 ) ) . withTrace ( pos , errorCtx ) . panic ( ) ;
2024-07-05 17:43:48 +03:00
}
}
// This implementation must match assertEqValues
2023-01-19 14:23:04 +02:00
bool EvalState : : eqValues ( Value & v1 , Value & v2 , const PosIdx pos , std : : string_view errorCtx )
2010-03-29 17:37:56 +03:00
{
2023-12-07 20:01:42 +02:00
forceValue ( v1 , pos ) ;
forceValue ( v2 , pos ) ;
2010-03-29 17:37:56 +03:00
2010-04-12 12:50:20 +03:00
/* !!! Hack to support some old broken code that relies on pointer
2013-10-24 17:41:04 +03:00
equality tests between sets . ( Specifically , builderDefs calls
uniqList on a list of sets . ) Will remove this eventually . */
2010-04-12 12:50:20 +03:00
if ( & v1 = = & v2 ) return true ;
2016-01-05 01:40:40 +02:00
// Special case type-compatibility between float and int
2020-12-17 15:45:45 +02:00
if ( v1 . type ( ) = = nInt & & v2 . type ( ) = = nFloat )
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
return v1 . integer ( ) . value = = v2 . fpoint ( ) ;
2020-12-17 15:45:45 +02:00
if ( v1 . type ( ) = = nFloat & & v2 . type ( ) = = nInt )
language: cleanly ban integer overflows
This also bans various sneaking of negative numbers from the language
into unsuspecting builtins as was exposed while auditing the
consequences of changing the Nix language integer type to a newtype.
It's unlikely that this change comprehensively ensures correctness when
passing integers out of the Nix language and we should probably add a
checked-narrowing function or something similar, but that's out of scope
for the immediate change.
During the development of this I found a few fun facts about the
language:
- You could overflow integers by converting from unsigned JSON values.
- You could overflow unsigned integers by converting negative numbers
into them when going into Nix config, into fetchTree, and into flake
inputs.
The flake inputs and Nix config cannot actually be tested properly
since they both ban thunks, however, we put in checks anyway because
it's possible these could somehow be used to do such shenanigans some
other way.
Note that Lix has banned Nix language integer overflows since the very
first public beta, but threw a SIGILL about them because we run with
-fsanitize=signed-overflow -fsanitize-undefined-trap-on-error in
production builds. Since the Nix language uses signed integers, overflow
was simply undefined behaviour, and since we defined that to trap, it
did.
Trapping on it was a bad UX, but we didn't even entirely notice
that we had done this at all until it was reported as a bug a couple of
months later (which is, to be fair, that flag working as intended), and
it's got enough production time that, aside from code that is IMHO buggy
(and which is, in any case, not in nixpkgs) such as
https://git.lix.systems/lix-project/lix/issues/445, we don't think
anyone doing anything reasonable actually depends on wrapping overflow.
Even for weird use cases such as doing funny bit crimes, it doesn't make
sense IMO to have wrapping behaviour, since two's complement arithmetic
overflow behaviour is so *aggressively* not what you want for *any* kind
of mathematics/algorithms. The Nix language exists for package
management, a domain where bit crimes are already only dubiously in
scope to begin with, and it makes a lot more sense for that domain for
the integers to never lose precision, either by throwing errors if they
would, or by being arbitrary-precision.
Fixes: https://github.com/NixOS/nix/issues/10968
Original-CL: https://gerrit.lix.systems/c/lix/+/1596
Change-Id: I51f253840c4af2ea5422b8a420aa5fafbf8fae75
2024-07-12 17:22:34 +03:00
return v1 . fpoint ( ) = = v2 . integer ( ) . value ;
2016-01-05 01:40:40 +02:00
// All other types are not compatible with each other.
2020-12-17 15:45:45 +02:00
if ( v1 . type ( ) ! = v2 . type ( ) ) return false ;
2010-04-12 12:50:20 +03:00
2020-12-17 15:45:45 +02:00
switch ( v1 . type ( ) ) {
2020-12-12 03:09:10 +02:00
case nInt :
2024-03-25 19:20:18 +02:00
return v1 . integer ( ) = = v2 . integer ( ) ;
2010-03-29 17:37:56 +03:00
2020-12-12 03:09:10 +02:00
case nBool :
2024-03-25 19:20:18 +02:00
return v1 . boolean ( ) = = v2 . boolean ( ) ;
2010-03-29 17:37:56 +03:00
2020-12-12 03:09:10 +02:00
case nString :
2023-12-10 10:25:20 +02:00
return strcmp ( v1 . c_str ( ) , v2 . c_str ( ) ) = = 0 ;
2010-03-29 17:37:56 +03:00
2020-12-12 03:09:10 +02:00
case nPath :
2023-10-18 16:32:31 +03:00
return
2023-10-20 17:58:33 +03:00
// FIXME: compare accessors by their fingerprint.
2024-03-25 19:20:18 +02:00
v1 . payload . path . accessor = = v2 . payload . path . accessor
& & strcmp ( v1 . payload . path . path , v2 . payload . path . path ) = = 0 ;
2010-03-31 23:09:20 +03:00
2020-12-12 03:09:10 +02:00
case nNull :
2010-03-31 12:54:12 +03:00
return true ;
2020-12-12 03:09:10 +02:00
case nList :
2015-07-23 23:05:09 +03:00
if ( v1 . listSize ( ) ! = v2 . listSize ( ) ) return false ;
2018-05-02 14:56:34 +03:00
for ( size_t n = 0 ; n < v1 . listSize ( ) ; + + n )
2023-01-19 14:23:04 +02:00
if ( ! eqValues ( * v1 . listElems ( ) [ n ] , * v2 . listElems ( ) [ n ] , pos , errorCtx ) ) return false ;
2010-03-29 17:37:56 +03:00
return true ;
2020-12-12 03:09:10 +02:00
case nAttrs : {
2013-10-24 17:41:04 +03:00
/* If both sets denote a derivation (type = "derivation"),
then compare their outPaths . */
2012-01-20 01:08:47 +02:00
if ( isDerivation ( v1 ) & & isDerivation ( v2 ) ) {
2024-03-25 19:20:18 +02:00
auto i = v1 . attrs ( ) - > get ( sOutPath ) ;
auto j = v2 . attrs ( ) - > get ( sOutPath ) ;
if ( i & & j )
2023-01-19 14:23:04 +02:00
return eqValues ( * i - > value , * j - > value , pos , errorCtx ) ;
2012-01-20 01:08:47 +02:00
}
2024-03-25 19:20:18 +02:00
if ( v1 . attrs ( ) - > size ( ) ! = v2 . attrs ( ) - > size ( ) ) return false ;
2012-01-20 01:08:47 +02:00
/* Otherwise, compare the attributes one by one. */
2024-03-25 19:20:18 +02:00
Bindings : : const_iterator i , j ;
for ( i = v1 . attrs ( ) - > begin ( ) , j = v2 . attrs ( ) - > begin ( ) ; i ! = v1 . attrs ( ) - > end ( ) ; + + i , + + j )
2023-01-19 14:23:04 +02:00
if ( i - > name ! = j - > name | | ! eqValues ( * i - > value , * j - > value , pos , errorCtx ) )
2010-05-07 15:11:05 +03:00
return false ;
2013-09-02 17:29:15 +03:00
2010-03-29 17:37:56 +03:00
return true ;
}
2010-04-01 13:55:36 +03:00
/* Functions are incomparable. */
2020-12-12 03:09:10 +02:00
case nFunction :
2010-04-01 13:55:36 +03:00
return false ;
2020-12-12 03:09:10 +02:00
case nExternal :
2024-03-25 19:20:18 +02:00
return * v1 . external ( ) = = * v2 . external ( ) ;
2014-11-30 20:16:19 +02:00
2020-12-12 03:09:10 +02:00
case nFloat :
2024-07-05 17:43:48 +03:00
// !!!
2024-03-25 19:20:18 +02:00
return v1 . fpoint ( ) = = v2 . fpoint ( ) ;
2016-01-05 01:40:40 +02:00
2023-04-03 19:03:20 +03:00
case nThunk : // Must not be left by forceValue
2024-07-11 12:37:45 +03:00
assert ( false ) ;
default : // Note that we pass compiler flags that should make `default:` unreachable.
error < EvalError > ( " eqValues: cannot compare %1% with %2% " , showType ( v1 ) , showType ( v2 ) ) . withTrace ( pos , errorCtx ) . panic ( ) ;
2010-03-29 17:37:56 +03:00
}
}
2023-09-01 13:20:54 +03:00
bool EvalState : : fullGC ( ) {
# if HAVE_BOEHMGC
GC_gcollect ( ) ;
// Check that it ran. We might replace this with a version that uses more
// of the boehm API to get this reliably, at a maintenance cost.
// We use a 1K margin because technically this has a race condtion, but we
// probably won't encounter it in practice, because the CLI isn't concurrent
// like that.
return GC_get_bytes_since_gc ( ) < 1024 ;
# else
return false ;
# endif
}
2023-10-09 17:25:53 +03:00
void EvalState : : maybePrintStats ( )
2003-10-31 19:09:31 +02:00
{
2019-11-22 17:06:44 +02:00
bool showStats = getEnv ( " NIX_SHOW_STATS " ) . value_or ( " 0 " ) ! = " 0 " ;
2012-02-04 15:27:11 +02:00
2023-09-01 13:20:54 +03:00
if ( showStats ) {
// Make the final heap size more deterministic.
# if HAVE_BOEHMGC
if ( ! fullGC ( ) ) {
warn ( " failed to perform a full GC before reporting stats " ) ;
}
# endif
printStatistics ( ) ;
}
}
void EvalState : : printStatistics ( )
{
2023-09-03 00:35:16 +03:00
# ifndef _WIN32 // TODO use portable implementation
2012-02-04 15:27:11 +02:00
struct rusage buf ;
getrusage ( RUSAGE_SELF , & buf ) ;
float cpuTime = buf . ru_utime . tv_sec + ( ( float ) buf . ru_utime . tv_usec / 1000000 ) ;
2023-09-03 00:35:16 +03:00
# endif
2012-02-04 15:27:11 +02:00
2014-10-05 01:39:28 +03:00
uint64_t bEnvs = nrEnvs * sizeof ( Env ) + nrValuesInEnvs * sizeof ( Value * ) ;
uint64_t bLists = nrListElems * sizeof ( Value * ) ;
uint64_t bValues = nrValues * sizeof ( Value ) ;
uint64_t bAttrsets = nrAttrsets * sizeof ( Bindings ) + nrAttrsInAttrsets * sizeof ( Attr ) ;
2015-03-18 17:24:54 +02:00
# if HAVE_BOEHMGC
GC_word heapSize , totalBytes ;
GC_get_heap_usage_safe ( & heapSize , 0 , 0 , 0 , & totalBytes ) ;
2024-07-22 13:56:01 +03:00
double gcFullOnlyTime = ( {
auto ms = GC_get_full_gc_total_time ( ) ;
ms * 0.001 ;
} ) ;
auto gcCycles = getGCCycles ( ) ;
2015-03-18 17:24:54 +02:00
# endif
2023-09-01 13:20:54 +03:00
auto outPath = getEnv ( " NIX_SHOW_STATS_PATH " ) . value_or ( " - " ) ;
std : : fstream fs ;
if ( outPath ! = " - " )
fs . open ( outPath , std : : fstream : : out ) ;
json topObj = json : : object ( ) ;
2023-09-03 00:35:16 +03:00
# ifndef _WIN32 // TODO implement
2023-09-01 13:20:54 +03:00
topObj [ " cpuTime " ] = cpuTime ;
2023-09-03 00:35:16 +03:00
# endif
2024-07-22 13:56:01 +03:00
topObj [ " time " ] = {
2024-07-31 23:04:18 +03:00
# ifndef _WIN32 // TODO implement
2024-07-22 13:56:01 +03:00
{ " cpu " , cpuTime } ,
2024-07-31 23:04:18 +03:00
# endif
# if HAVE_BOEHMGC
2024-07-22 13:56:01 +03:00
{ GC_is_incremental_mode ( ) ? " gcNonIncremental " : " gc " , gcFullOnlyTime } ,
{ GC_is_incremental_mode ( ) ? " gcNonIncrementalFraction " : " gcFraction " , gcFullOnlyTime / cpuTime } ,
# endif
} ;
2023-09-01 13:20:54 +03:00
topObj [ " envs " ] = {
{ " number " , nrEnvs } ,
{ " elements " , nrValuesInEnvs } ,
{ " bytes " , bEnvs } ,
} ;
topObj [ " nrExprs " ] = Expr : : nrExprs ;
topObj [ " list " ] = {
{ " elements " , nrListElems } ,
{ " bytes " , bLists } ,
{ " concats " , nrListConcats } ,
} ;
topObj [ " values " ] = {
{ " number " , nrValues } ,
{ " bytes " , bValues } ,
} ;
topObj [ " symbols " ] = {
{ " number " , symbols . size ( ) } ,
{ " bytes " , symbols . totalSize ( ) } ,
} ;
topObj [ " sets " ] = {
{ " number " , nrAttrsets } ,
{ " bytes " , bAttrsets } ,
{ " elements " , nrAttrsInAttrsets } ,
} ;
topObj [ " sizes " ] = {
{ " Env " , sizeof ( Env ) } ,
{ " Value " , sizeof ( Value ) } ,
{ " Bindings " , sizeof ( Bindings ) } ,
{ " Attr " , sizeof ( Attr ) } ,
} ;
topObj [ " nrOpUpdates " ] = nrOpUpdates ;
topObj [ " nrOpUpdateValuesCopied " ] = nrOpUpdateValuesCopied ;
topObj [ " nrThunks " ] = nrThunks ;
topObj [ " nrAvoided " ] = nrAvoided ;
topObj [ " nrLookups " ] = nrLookups ;
topObj [ " nrPrimOpCalls " ] = nrPrimOpCalls ;
topObj [ " nrFunctionCalls " ] = nrFunctionCalls ;
2018-09-02 01:50:22 +03:00
# if HAVE_BOEHMGC
2023-09-01 13:20:54 +03:00
topObj [ " gc " ] = {
{ " heapSize " , heapSize } ,
{ " totalBytes " , totalBytes } ,
2024-07-22 13:56:01 +03:00
{ " cycles " , gcCycles } ,
2023-09-01 13:20:54 +03:00
} ;
2018-09-02 01:50:22 +03:00
# endif
2019-04-12 00:04:13 +03:00
2023-09-01 13:20:54 +03:00
if ( countCalls ) {
topObj [ " primops " ] = primOpCalls ;
{
auto & list = topObj [ " functions " ] ;
list = json : : array ( ) ;
for ( auto & [ fun , count ] : functionCalls ) {
json obj = json : : object ( ) ;
if ( fun - > name )
obj [ " name " ] = ( std : : string_view ) symbols [ fun - > name ] ;
else
obj [ " name " ] = nullptr ;
if ( auto pos = positions [ fun - > pos ] ) {
if ( auto path = std : : get_if < SourcePath > ( & pos . origin ) )
obj [ " file " ] = path - > to_string ( ) ;
obj [ " line " ] = pos . line ;
obj [ " column " ] = pos . column ;
2018-09-05 22:57:54 +03:00
}
2023-09-01 13:20:54 +03:00
obj [ " count " ] = count ;
list . push_back ( obj ) ;
2018-09-05 22:57:54 +03:00
}
2023-09-01 13:20:54 +03:00
}
{
auto list = topObj [ " attributes " ] ;
list = json : : array ( ) ;
for ( auto & i : attrSelects ) {
json obj = json : : object ( ) ;
if ( auto pos = positions [ i . first ] ) {
if ( auto path = std : : get_if < SourcePath > ( & pos . origin ) )
obj [ " file " ] = path - > to_string ( ) ;
obj [ " line " ] = pos . line ;
obj [ " column " ] = pos . column ;
2018-09-05 22:57:54 +03:00
}
2023-09-01 13:20:54 +03:00
obj [ " count " ] = i . second ;
list . push_back ( obj ) ;
2018-09-05 22:57:54 +03:00
}
}
2023-09-01 13:20:54 +03:00
}
2019-04-12 00:04:13 +03:00
2023-09-01 13:20:54 +03:00
if ( getEnv ( " NIX_SHOW_SYMBOLS " ) . value_or ( " 0 " ) ! = " 0 " ) {
// XXX: overrides earlier assignment
topObj [ " symbols " ] = json : : array ( ) ;
auto & list = topObj [ " symbols " ] ;
symbols . dump ( [ & ] ( const std : : string & s ) { list . emplace_back ( s ) ; } ) ;
}
if ( outPath = = " - " ) {
std : : cerr < < topObj . dump ( 2 ) < < std : : endl ;
} else {
fs < < topObj . dump ( 2 ) < < std : : endl ;
2012-08-13 06:29:28 +03:00
}
2003-10-31 19:09:31 +02:00
}
2006-09-05 00:06:23 +03:00
2010-04-07 16:55:46 +03:00
2024-07-08 15:36:36 +03:00
SourcePath resolveExprPath ( SourcePath path , bool addDefaultNix )
2024-01-15 17:52:18 +02:00
{
unsigned int followCount = 0 , maxFollow = 1024 ;
/* If `path' is a symlink, follow it. This is so that relative
path references work . */
while ( ! path . path . isRoot ( ) ) {
// Basic cycle/depth limit to avoid infinite loops.
if ( + + followCount > = maxFollow )
throw Error ( " too many symbolic links encountered while traversing the path '%s' " , path ) ;
2024-02-05 16:13:11 +02:00
auto p = path . parent ( ) . resolveSymlinks ( ) / path . baseName ( ) ;
2024-05-03 13:14:01 +03:00
if ( p . lstat ( ) . type ! = SourceAccessor : : tSymlink ) break ;
2024-01-15 17:52:18 +02:00
path = { path . accessor , CanonPath ( p . readLink ( ) , path . path . parent ( ) . value_or ( CanonPath : : root ) ) } ;
}
/* If `path' refers to a directory, append `/default.nix'. */
2024-07-08 15:36:36 +03:00
if ( addDefaultNix & & path . resolveSymlinks ( ) . lstat ( ) . type = = SourceAccessor : : tDirectory )
2024-02-05 16:13:11 +02:00
return path / " default.nix " ;
2024-01-15 17:52:18 +02:00
return path ;
}
Expr * EvalState : : parseExprFromFile ( const SourcePath & path )
{
return parseExprFromFile ( path , staticBaseEnv ) ;
}
Expr * EvalState : : parseExprFromFile ( const SourcePath & path , std : : shared_ptr < StaticEnv > & staticEnv )
{
auto buffer = path . resolveSymlinks ( ) . readFile ( ) ;
// readFile hopefully have left some extra space for terminators
buffer . append ( " \0 \0 " , 2 ) ;
return parse ( buffer . data ( ) , buffer . size ( ) , Pos : : Origin ( path ) , path . parent ( ) , staticEnv ) ;
}
Expr * EvalState : : parseExprFromString ( std : : string s_ , const SourcePath & basePath , std : : shared_ptr < StaticEnv > & staticEnv )
{
2024-01-29 07:19:23 +02:00
// NOTE this method (and parseStdin) must take care to *fully copy* their input
// into their respective Pos::Origin until the parser stops overwriting its input
// data.
auto s = make_ref < std : : string > ( s_ ) ;
s_ . append ( " \0 \0 " , 2 ) ;
return parse ( s_ . data ( ) , s_ . size ( ) , Pos : : String { . source = s } , basePath , staticEnv ) ;
2024-01-15 17:52:18 +02:00
}
Expr * EvalState : : parseExprFromString ( std : : string s , const SourcePath & basePath )
{
return parseExprFromString ( std : : move ( s ) , basePath , staticBaseEnv ) ;
}
Expr * EvalState : : parseStdin ( )
{
2024-01-29 07:19:23 +02:00
// NOTE this method (and parseExprFromString) must take care to *fully copy* their
// input into their respective Pos::Origin until the parser stops overwriting its
// input data.
2024-01-15 17:52:18 +02:00
//Activity act(*logger, lvlTalkative, "parsing standard input");
auto buffer = drainFD ( 0 ) ;
// drainFD should have left some extra space for terminators
buffer . append ( " \0 \0 " , 2 ) ;
2024-01-29 07:19:23 +02:00
auto s = make_ref < std : : string > ( buffer ) ;
return parse ( buffer . data ( ) , buffer . size ( ) , Pos : : Stdin { . source = s } , rootPath ( " . " ) , staticBaseEnv ) ;
2024-01-15 17:52:18 +02:00
}
SourcePath EvalState : : findFile ( const std : : string_view path )
{
2024-04-13 18:35:15 +03:00
return findFile ( lookupPath , path ) ;
2024-01-15 17:52:18 +02:00
}
2024-04-13 18:35:15 +03:00
SourcePath EvalState : : findFile ( const LookupPath & lookupPath , const std : : string_view path , const PosIdx pos )
2024-01-15 17:52:18 +02:00
{
2024-04-13 18:35:15 +03:00
for ( auto & i : lookupPath . elements ) {
2024-01-15 17:52:18 +02:00
auto suffixOpt = i . prefix . suffixIfPotentialMatch ( path ) ;
if ( ! suffixOpt ) continue ;
auto suffix = * suffixOpt ;
2024-04-13 18:35:15 +03:00
auto rOpt = resolveLookupPathPath ( i . path ) ;
2024-01-15 17:52:18 +02:00
if ( ! rOpt ) continue ;
auto r = * rOpt ;
Path res = suffix = = " " ? r : concatStrings ( r , " / " , suffix ) ;
if ( pathExists ( res ) ) return rootPath ( CanonPath ( canonPath ( res ) ) ) ;
}
if ( hasPrefix ( path , " nix/ " ) )
return { corepkgsFS , CanonPath ( path . substr ( 3 ) ) } ;
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 < ThrownError > (
2024-06-14 19:41:09 +03:00
settings . pureEval
2024-01-15 17:52:18 +02:00
? " cannot look up '<%s>' in pure evaluation mode (use '--impure' to override) "
: " file '%s' was not found in the Nix search path (add it using $NIX_PATH or -I) " ,
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
path
) . atPos ( pos ) . debugThrow ( ) ;
2024-01-15 17:52:18 +02:00
}
2024-04-13 18:35:15 +03:00
std : : optional < std : : string > EvalState : : resolveLookupPathPath ( const LookupPath : : Path & value0 , bool initAccessControl )
2024-01-15 17:52:18 +02:00
{
auto & value = value0 . s ;
2024-04-13 18:35:15 +03:00
auto i = lookupPathResolved . find ( value ) ;
if ( i ! = lookupPathResolved . end ( ) ) return i - > second ;
2024-01-15 17:52:18 +02:00
2024-06-25 00:33:15 +03:00
auto finish = [ & ] ( std : : string res ) {
debug ( " resolved search path element '%s' to '%s' " , value , res ) ;
lookupPathResolved . emplace ( value , res ) ;
return res ;
} ;
2024-01-15 17:52:18 +02:00
if ( EvalSettings : : isPseudoUrl ( value ) ) {
try {
2024-02-20 13:57:36 +02:00
auto accessor = fetchers : : downloadTarball (
2024-08-12 16:47:02 +03:00
store ,
fetchSettings ,
EvalSettings : : resolvePseudoUrl ( value ) ) ;
2024-02-20 13:57:36 +02:00
auto storePath = fetchToStore ( * store , SourcePath ( accessor ) , FetchMode : : Copy ) ;
2024-06-25 00:33:15 +03:00
return finish ( store - > toRealPath ( storePath ) ) ;
2024-02-20 13:57:36 +02:00
} catch ( Error & e ) {
2024-01-15 17:52:18 +02:00
logWarning ( {
2024-02-04 06:35:19 +02:00
. msg = HintFmt ( " Nix search path entry '%1%' cannot be downloaded, ignoring " , value )
2024-01-15 17:52:18 +02:00
} ) ;
}
}
2024-06-25 00:33:15 +03:00
if ( auto colPos = value . find ( ' : ' ) ; colPos ! = value . npos ) {
auto scheme = value . substr ( 0 , colPos ) ;
auto rest = value . substr ( colPos + 1 ) ;
if ( auto * hook = get ( settings . lookupPathHooks , scheme ) ) {
auto res = ( * hook ) ( store , rest ) ;
if ( res )
return finish ( std : : move ( * res ) ) ;
}
2024-01-15 17:52:18 +02:00
}
2024-06-25 00:33:15 +03:00
{
2024-01-15 17:52:18 +02:00
auto path = absPath ( value ) ;
/* Allow access to paths in the search path. */
if ( initAccessControl ) {
allowPath ( path ) ;
if ( store - > isInStore ( path ) ) {
try {
StorePathSet closure ;
store - > computeFSClosure ( store - > toStorePath ( path ) . first , closure ) ;
for ( auto & p : closure )
allowPath ( p ) ;
} catch ( InvalidPath & ) { }
}
}
if ( pathExists ( path ) )
2024-06-25 00:33:15 +03:00
return finish ( std : : move ( path ) ) ;
2024-01-15 17:52:18 +02:00
else {
logWarning ( {
2024-02-04 06:35:19 +02:00
. msg = HintFmt ( " Nix search path entry '%1%' does not exist, ignoring " , value )
2024-01-15 17:52:18 +02:00
} ) ;
}
}
2024-06-25 00:33:15 +03:00
debug ( " failed to resolve search path element '%s' " , value ) ;
return std : : nullopt ;
2024-01-15 17:52:18 +02:00
}
2024-01-15 17:52:18 +02:00
Expr * EvalState : : parse (
char * text ,
size_t length ,
Pos : : Origin origin ,
const SourcePath & basePath ,
std : : shared_ptr < StaticEnv > & staticEnv )
{
2024-07-09 20:25:45 +03:00
DocCommentMap tmpDocComments ; // Only used when not origin is not a SourcePath
DocCommentMap * docComments = & tmpDocComments ;
if ( auto sourcePath = std : : get_if < SourcePath > ( & origin ) ) {
auto [ it , _ ] = positionToDocComment . try_emplace ( * sourcePath ) ;
docComments = & it - > second ;
}
auto result = parseExprFromBuf ( text , length , origin , basePath , symbols , settings , positions , * docComments , rootFS , exprSymbols ) ;
2024-01-15 17:52:18 +02:00
result - > bindVars ( * this , staticEnv ) ;
return result ;
}
2024-07-09 20:25:45 +03:00
DocComment EvalState : : getDocCommentForPos ( PosIdx pos )
{
auto pos2 = positions [ pos ] ;
auto path = pos2 . getSourcePath ( ) ;
if ( ! path )
return { } ;
auto table = positionToDocComment . find ( * path ) ;
if ( table = = positionToDocComment . end ( ) )
return { } ;
auto it = table - > second . find ( pos ) ;
if ( it = = table - > second . end ( ) )
return { } ;
return it - > second ;
}
2024-01-15 17:52:18 +02:00
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
std : : string ExternalValueBase : : coerceToString ( EvalState & state , const PosIdx & pos , NixStringContext & context , bool copyMore , bool copyToStore ) const
2014-11-30 20:16:19 +02:00
{
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
state . error < TypeError > (
" cannot coerce %1% to a string: %2% " , showType ( ) , * this
) . atPos ( pos ) . debugThrow ( ) ;
2014-11-30 20:16:19 +02:00
}
2024-05-17 01:46:38 +03:00
bool ExternalValueBase : : operator = = ( const ExternalValueBase & b ) const noexcept
2014-11-30 20:16:19 +02:00
{
return false ;
}
2014-12-02 17:02:03 +02:00
std : : ostream & operator < < ( std : : ostream & str , const ExternalValueBase & v ) {
2014-11-30 20:16:19 +02:00
return v . print ( str ) ;
}
2006-09-05 00:06:23 +03:00
}