2003-10-30 18:48:26 +02:00
# include "eval.hh"
2023-07-31 16:19:19 +03:00
# include "eval-settings.hh"
2006-09-05 00:06:23 +03:00
# include "hash.hh"
2023-11-16 14:04:27 +02:00
# include "primops.hh"
2023-12-07 02:03:01 +02:00
# include "print-options.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"
2006-12-01 22:51:18 +02:00
# include "globals.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"
2023-10-18 16:32:31 +03:00
# include "fs-input-accessor.hh"
2023-11-30 22:54:53 +02:00
# include "filtering-input-accessor.hh"
2023-10-18 18:34:58 +03:00
# include "memory-input-accessor.hh"
2023-10-25 07:43:36 +03:00
# include "signals.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"
# include "flake/flakeref.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>
2019-04-12 19:31:33 +03:00
# include <chrono>
2022-11-29 01:25:36 +02:00
# include <iostream>
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>
# include <sys/resource.h>
2018-09-02 01:50:22 +03:00
# include <fstream>
2021-12-23 00:38:49 +02:00
# include <functional>
2023-12-07 02:03:01 +02:00
# include <iostream>
2010-03-29 17:37:56 +03:00
2018-06-11 17:10:50 +03:00
# include <sys/resource.h>
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
2010-10-22 16:39:15 +03:00
# if HAVE_BOEHMGC
2020-04-16 17:28:07 +03:00
# define GC_INCLUDE_NEW
2010-10-20 14:38:30 +03:00
# include <gc/gc.h>
# include <gc/gc_cpp.h>
2020-10-30 21:55:53 +02:00
# include <boost/coroutine2/coroutine.hpp>
# include <boost/coroutine2/protected_fixedsize_stack.hpp>
# include <boost/context/stack_context.hpp>
2010-10-22 16:39:15 +03:00
# endif
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 ( ) ) {
2019-03-21 15:32:20 +02:00
primOp = primOp - > primOpApp . left ;
}
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
}
abort ( ) ;
}
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 ) {
2019-09-09 17:34:44 +03:00
case tString : return v . string . context ? " a string with context " : " a string " ;
2019-03-21 15:32:20 +02:00
case tPrimOp :
2022-02-25 17:00:00 +02:00
return fmt ( " the built-in function '%s' " , std : : string ( v . primOp - > name ) ) ;
2019-03-21 15:32:20 +02:00
case tPrimOpApp :
2022-02-25 17:00:00 +02:00
return fmt ( " the partially applied built-in function '%s' " , std : : string ( getPrimOp ( v ) - > primOp - > name ) ) ;
2014-11-30 20:16:19 +02:00
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 ) {
2022-03-04 20:31:59 +02:00
case tAttrs : return attrs - > pos ;
2021-01-08 23:27:00 +02:00
case tLambda : return lambda . fun - > pos ;
case tApp : return app . left - > determinePos ( pos ) ;
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
2019-09-09 18:34:38 +03:00
| | ( dynamic_cast < ExprAttrs * > ( thunk . expr )
& & ( ( ExprAttrs * ) thunk . expr ) - > dynamicAttrs . empty ( ) )
2020-10-26 21:37:11 +02:00
| | dynamic_cast < ExprLambda * > ( thunk . expr )
| | dynamic_cast < ExprList * > ( thunk . expr ) ) ;
2019-09-09 18:34:38 +03:00
}
2014-04-04 18:53:52 +03:00
# if HAVE_BOEHMGC
2013-11-23 22:19:36 +02:00
/* Called when the Boehm GC runs out of memory. */
static void * oomHandler ( size_t requested )
{
/* Convert this to a proper C++ exception. */
throw std : : bad_alloc ( ) ;
}
2020-10-30 21:55:53 +02:00
class BoehmGCStackAllocator : public StackAllocator {
BoehmGCStackAllocator: ignore stack protection page
This fixes a crash that looks like:
```
Thread 1 "nix-build" received signal SIGSEGV, Segmentation fault.
0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
(gdb) bt
0 0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
1 0x00007ffff7adeefb in GC_push_all_stacks () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
2 0x00007ffff7ad5ac7 in GC_mark_some () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
3 0x00007ffff7ad77bd in GC_stopped_mark () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
4 0x00007ffff7adbe3a in GC_try_to_collect_inner.part.0 () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
5 0x00007ffff7adc2a2 in GC_collect_or_expand () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
6 0x00007ffff7adc4f8 in GC_allocobj () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
7 0x00007ffff7adc88f in GC_generic_malloc_inner () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
8 0x00007ffff7ae1a04 in GC_generic_malloc_many () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
9 0x00007ffff7ae1c72 in GC_malloc_kind () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
10 0x00007ffff7e003d6 in nix::EvalState::allocValue() () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
11 0x00007ffff7e04b9c in nix::EvalState::callPrimOp(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
12 0x00007ffff7e0a773 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
13 0x00007ffff7e0a91d in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
14 0x00007ffff7e0a8f8 in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
15 0x00007ffff7e0e0e8 in nix::ExprOpNEq::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
16 0x00007ffff7e0d708 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
17 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
18 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
19 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
20 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
21 0x00007ffff7e09e19 in nix::ExprOpNot::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
22 0x00007ffff7e0a792 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
23 0x00007ffff7e8cba0 in nix::addPath(nix::EvalState&, nix::Pos const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Value*, nix::FileIngestionMethod, std::optional<nix::Hash>, nix::Value&)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
24 0x00007ffff752e6f9 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
25 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
26 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
27 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
28 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
29 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
30 0x00007ffff757f8c0 in void boost::context::detail::fiber_entry<boost::context::detail::fiber_record<boost::context::fiber, nix::VirtualStackAllocator, boost::coroutines2::detail::pull_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::control_block::control_block<nix::VirtualStackAllocator, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}>(boost::context::preallocated, nix::VirtualStackAllocator&&, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}&&)::{lambda(boost::context::fiber&&)#1}> >(boost::context::detail::transfer_t) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
31 0x00007ffff6f331ef in make_fcontext () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libboost_context.so.1.69.0
32 0x0000000000000000 in ?? ()
```
2020-11-16 12:03:53 +02:00
boost : : coroutines2 : : protected_fixedsize_stack stack {
// We allocate 8 MB, the default max stack size on NixOS.
// A smaller stack might be quicker to allocate but reduces the stack
// depth available for source filter expressions etc.
std : : max ( boost : : context : : stack_traits : : default_size ( ) , static_cast < std : : size_t > ( 8 * 1024 * 1024 ) )
2020-10-31 00:18:24 +02:00
} ;
2020-10-30 21:55:53 +02:00
BoehmGCStackAllocator: ignore stack protection page
This fixes a crash that looks like:
```
Thread 1 "nix-build" received signal SIGSEGV, Segmentation fault.
0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
(gdb) bt
0 0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
1 0x00007ffff7adeefb in GC_push_all_stacks () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
2 0x00007ffff7ad5ac7 in GC_mark_some () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
3 0x00007ffff7ad77bd in GC_stopped_mark () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
4 0x00007ffff7adbe3a in GC_try_to_collect_inner.part.0 () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
5 0x00007ffff7adc2a2 in GC_collect_or_expand () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
6 0x00007ffff7adc4f8 in GC_allocobj () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
7 0x00007ffff7adc88f in GC_generic_malloc_inner () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
8 0x00007ffff7ae1a04 in GC_generic_malloc_many () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
9 0x00007ffff7ae1c72 in GC_malloc_kind () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
10 0x00007ffff7e003d6 in nix::EvalState::allocValue() () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
11 0x00007ffff7e04b9c in nix::EvalState::callPrimOp(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
12 0x00007ffff7e0a773 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
13 0x00007ffff7e0a91d in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
14 0x00007ffff7e0a8f8 in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
15 0x00007ffff7e0e0e8 in nix::ExprOpNEq::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
16 0x00007ffff7e0d708 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
17 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
18 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
19 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
20 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
21 0x00007ffff7e09e19 in nix::ExprOpNot::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
22 0x00007ffff7e0a792 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
23 0x00007ffff7e8cba0 in nix::addPath(nix::EvalState&, nix::Pos const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Value*, nix::FileIngestionMethod, std::optional<nix::Hash>, nix::Value&)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
24 0x00007ffff752e6f9 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
25 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
26 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
27 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
28 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
29 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
30 0x00007ffff757f8c0 in void boost::context::detail::fiber_entry<boost::context::detail::fiber_record<boost::context::fiber, nix::VirtualStackAllocator, boost::coroutines2::detail::pull_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::control_block::control_block<nix::VirtualStackAllocator, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}>(boost::context::preallocated, nix::VirtualStackAllocator&&, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}&&)::{lambda(boost::context::fiber&&)#1}> >(boost::context::detail::transfer_t) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
31 0x00007ffff6f331ef in make_fcontext () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libboost_context.so.1.69.0
32 0x0000000000000000 in ?? ()
```
2020-11-16 12:03:53 +02:00
// This is specific to boost::coroutines2::protected_fixedsize_stack.
// The stack protection page is included in sctx.size, so we have to
// subtract one page size from the stack size.
std : : size_t pfss_usable_stack_size ( boost : : context : : stack_context & sctx ) {
return sctx . size - boost : : context : : stack_traits : : page_size ( ) ;
}
2020-10-30 21:55:53 +02:00
public :
boost : : context : : stack_context allocate ( ) override {
auto sctx = stack . allocate ( ) ;
BoehmGCStackAllocator: ignore stack protection page
This fixes a crash that looks like:
```
Thread 1 "nix-build" received signal SIGSEGV, Segmentation fault.
0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
(gdb) bt
0 0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
1 0x00007ffff7adeefb in GC_push_all_stacks () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
2 0x00007ffff7ad5ac7 in GC_mark_some () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
3 0x00007ffff7ad77bd in GC_stopped_mark () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
4 0x00007ffff7adbe3a in GC_try_to_collect_inner.part.0 () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
5 0x00007ffff7adc2a2 in GC_collect_or_expand () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
6 0x00007ffff7adc4f8 in GC_allocobj () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
7 0x00007ffff7adc88f in GC_generic_malloc_inner () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
8 0x00007ffff7ae1a04 in GC_generic_malloc_many () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
9 0x00007ffff7ae1c72 in GC_malloc_kind () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
10 0x00007ffff7e003d6 in nix::EvalState::allocValue() () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
11 0x00007ffff7e04b9c in nix::EvalState::callPrimOp(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
12 0x00007ffff7e0a773 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
13 0x00007ffff7e0a91d in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
14 0x00007ffff7e0a8f8 in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
15 0x00007ffff7e0e0e8 in nix::ExprOpNEq::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
16 0x00007ffff7e0d708 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
17 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
18 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
19 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
20 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
21 0x00007ffff7e09e19 in nix::ExprOpNot::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
22 0x00007ffff7e0a792 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
23 0x00007ffff7e8cba0 in nix::addPath(nix::EvalState&, nix::Pos const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Value*, nix::FileIngestionMethod, std::optional<nix::Hash>, nix::Value&)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
24 0x00007ffff752e6f9 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
25 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
26 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
27 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
28 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
29 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
30 0x00007ffff757f8c0 in void boost::context::detail::fiber_entry<boost::context::detail::fiber_record<boost::context::fiber, nix::VirtualStackAllocator, boost::coroutines2::detail::pull_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::control_block::control_block<nix::VirtualStackAllocator, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}>(boost::context::preallocated, nix::VirtualStackAllocator&&, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}&&)::{lambda(boost::context::fiber&&)#1}> >(boost::context::detail::transfer_t) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
31 0x00007ffff6f331ef in make_fcontext () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libboost_context.so.1.69.0
32 0x0000000000000000 in ?? ()
```
2020-11-16 12:03:53 +02:00
// Stacks generally start at a high address and grow to lower addresses.
// Architectures that do the opposite are rare; in fact so rare that
// boost_routine does not implement it.
// So we subtract the stack size.
GC_add_roots ( static_cast < char * > ( sctx . sp ) - pfss_usable_stack_size ( sctx ) , sctx . sp ) ;
2020-10-30 21:55:53 +02:00
return sctx ;
}
void deallocate ( boost : : context : : stack_context sctx ) override {
BoehmGCStackAllocator: ignore stack protection page
This fixes a crash that looks like:
```
Thread 1 "nix-build" received signal SIGSEGV, Segmentation fault.
0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
(gdb) bt
0 0x00007ffff7ad22a0 in GC_push_all_eager () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
1 0x00007ffff7adeefb in GC_push_all_stacks () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
2 0x00007ffff7ad5ac7 in GC_mark_some () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
3 0x00007ffff7ad77bd in GC_stopped_mark () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
4 0x00007ffff7adbe3a in GC_try_to_collect_inner.part.0 () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
5 0x00007ffff7adc2a2 in GC_collect_or_expand () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
6 0x00007ffff7adc4f8 in GC_allocobj () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
7 0x00007ffff7adc88f in GC_generic_malloc_inner () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
8 0x00007ffff7ae1a04 in GC_generic_malloc_many () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
9 0x00007ffff7ae1c72 in GC_malloc_kind () from /nix/store/p1z58l18klf88iijpd0qi8yd2n9lhlk4-boehm-gc-8.0.4/lib/libgc.so.1
10 0x00007ffff7e003d6 in nix::EvalState::allocValue() () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
11 0x00007ffff7e04b9c in nix::EvalState::callPrimOp(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
12 0x00007ffff7e0a773 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
13 0x00007ffff7e0a91d in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
14 0x00007ffff7e0a8f8 in nix::ExprApp::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
15 0x00007ffff7e0e0e8 in nix::ExprOpNEq::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
16 0x00007ffff7e0d708 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
17 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
18 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
19 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
20 0x00007ffff7e0d695 in nix::ExprOpOr::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
21 0x00007ffff7e09e19 in nix::ExprOpNot::eval(nix::EvalState&, nix::Env&, nix::Value&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
22 0x00007ffff7e0a792 in nix::EvalState::callFunction(nix::Value&, nix::Value&, nix::Value&, nix::Pos const&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
23 0x00007ffff7e8cba0 in nix::addPath(nix::EvalState&, nix::Pos const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Value*, nix::FileIngestionMethod, std::optional<nix::Hash>, nix::Value&)::{lambda(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)#1}::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixexpr.so
24 0x00007ffff752e6f9 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
25 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
26 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
27 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
28 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
29 0x00007ffff752e8e2 in nix::dump(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, nix::Sink&, std::function<bool (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>&) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
30 0x00007ffff757f8c0 in void boost::context::detail::fiber_entry<boost::context::detail::fiber_record<boost::context::fiber, nix::VirtualStackAllocator, boost::coroutines2::detail::pull_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::control_block::control_block<nix::VirtualStackAllocator, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}>(boost::context::preallocated, nix::VirtualStackAllocator&&, nix::sinkToSource(std::function<void (nix::Sink&)>, std::function<void ()>)::SinkToSource::read(char*, unsigned long)::{lambda(boost::coroutines2::detail::push_coroutine<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >&)#1}&&)::{lambda(boost::context::fiber&&)#1}> >(boost::context::detail::transfer_t) () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libnixutil.so
31 0x00007ffff6f331ef in make_fcontext () from /nix/store/hzdzcv9d3bc8rlsaphh7x54zsf0x8nx6-nix-2.4pre20210601_5985b8b/lib/libboost_context.so.1.69.0
32 0x0000000000000000 in ?? ()
```
2020-11-16 12:03:53 +02:00
GC_remove_roots ( static_cast < char * > ( sctx . sp ) - pfss_usable_stack_size ( sctx ) , sctx . sp ) ;
2020-10-30 21:55:53 +02:00
stack . deallocate ( sctx ) ;
}
} ;
static BoehmGCStackAllocator boehmGCStackAllocator ;
2014-04-04 18:53:52 +03:00
# endif
2013-11-23 22:19:36 +02: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
}
}
2023-02-10 16:04:17 +02:00
# if HAVE_BOEHMGC
/* Disable GC while this object lives. Used by CoroutineContext.
*
* Boehm keeps a count of GC_disable ( ) and GC_enable ( ) calls ,
* and only enables GC when the count matches .
*/
class BoehmDisableGC {
2023-02-03 18:50:01 +02:00
public :
BoehmDisableGC ( ) {
GC_disable ( ) ;
} ;
2023-02-10 16:04:17 +02:00
~ BoehmDisableGC ( ) {
2023-02-03 18:50:01 +02:00
GC_enable ( ) ;
} ;
} ;
2023-02-10 16:04:17 +02:00
# endif
2014-01-01 01:56:26 +02:00
2015-03-19 21:02:37 +02:00
static bool gcInitialised = false ;
void initGC ( )
{
if ( gcInitialised ) return ;
# if HAVE_BOEHMGC
/* Initialise the Boehm garbage collector. */
2018-06-12 16:41:37 +03:00
/* Don't look for interior pointers. This reduces the odds of
misdetection a bit . */
2015-03-19 21:10:08 +02:00
GC_set_all_interior_pointers ( 0 ) ;
2018-06-12 16:41:37 +03:00
/* We don't have any roots in data segments, so don't scan from
there . */
GC_set_no_dls ( 1 ) ;
2015-03-19 21:02:37 +02:00
GC_INIT ( ) ;
2017-04-14 15:42:20 +03:00
GC_set_oom_fn ( oomHandler ) ;
2015-03-19 21:02:37 +02:00
2020-10-30 21:55:53 +02:00
StackAllocator : : defaultAllocator = & boehmGCStackAllocator ;
2023-02-03 18:50:01 +02:00
2023-03-01 16:07:00 +02:00
# if NIX_BOEHM_PATCH_VERSION != 1
2023-03-03 12:43:47 +02:00
printTalkative ( " Unpatched BoehmGC, disabling GC inside coroutines " ) ;
2023-02-03 18:50:01 +02:00
/* Used to disable GC when entering coroutines on macOS */
2023-03-01 16:07:00 +02:00
create_coro_gc_hook = [ ] ( ) - > std : : shared_ptr < void > {
2023-02-10 16:04:17 +02:00
return std : : make_shared < BoehmDisableGC > ( ) ;
2023-02-03 18:50:01 +02:00
} ;
2023-03-01 16:07:00 +02:00
# endif
2023-02-03 18:50:01 +02:00
2015-03-19 21:02:37 +02:00
/* Set the initial heap size to something fairly big (25% of
physical RAM , up to a maximum of 384 MiB ) so that in most cases
we don ' t need to garbage collect at all . ( Collection has a
fairly significant overhead . ) The heap size can be overridden
through libgc ' s GC_INITIAL_HEAP_SIZE environment variable . We
should probably also provide a nix . conf setting for this . Note
that GC_expand_hp ( ) causes a lot of virtual , but not physical
( resident ) memory to be allocated . This might be a problem on
systems that don ' t overcommit . */
2019-11-22 17:06:44 +02:00
if ( ! getEnv ( " GC_INITIAL_HEAP_SIZE " ) ) {
2015-03-19 21:02:37 +02:00
size_t size = 32 * 1024 * 1024 ;
# if HAVE_SYSCONF && defined(_SC_PAGESIZE) && defined(_SC_PHYS_PAGES)
size_t maxSize = 384 * 1024 * 1024 ;
long pageSize = sysconf ( _SC_PAGESIZE ) ;
long pages = sysconf ( _SC_PHYS_PAGES ) ;
if ( pageSize ! = - 1 )
size = ( pageSize * pages ) / 4 ; // 25% of RAM
if ( size > maxSize ) size = maxSize ;
# endif
2023-03-02 16:44:19 +02:00
debug ( " setting initial heap size to %1% bytes " , size ) ;
2015-03-19 21:02:37 +02:00
GC_expand_hp ( size ) ;
}
# endif
gcInitialised = true ;
}
2021-06-29 22:09:48 +03:00
EvalState : : EvalState (
2023-06-23 20:51:25 +03:00
const SearchPath & _searchPath ,
2021-06-29 22:09:48 +03:00
ref < Store > store ,
std : : shared_ptr < Store > buildStore )
2010-04-13 15:25:42 +03:00
: sWith ( symbols . create ( " <with> " ) )
, 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 " ) )
, 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 (
2023-11-30 22:54:53 +02:00
evalSettings . restrictEval | | evalSettings . pureEval
? ref < InputAccessor > ( AllowListInputAccessor : : create ( makeFSInputAccessor ( CanonPath : : root ) , { } ,
2023-11-30 17:16:17 +02:00
[ ] ( const CanonPath & path ) - > RestrictedPathError {
auto modeInformation = evalSettings . pureEval
? " in pure evaluation mode (use '--impure' to override) "
: " in restricted mode " ;
throw RestrictedPathError ( " access to absolute path '%1%' is forbidden %2% " , path , modeInformation ) ;
} ) )
2023-11-30 22:54:53 +02:00
: makeFSInputAccessor ( CanonPath : : root ) )
2023-10-18 18:34:58 +03:00
, corepkgsFS ( makeMemoryInputAccessor ( ) )
, internalFS ( makeMemoryInputAccessor ( ) )
, derivationInternal { corepkgsFS - > addFile (
CanonPath ( " derivation-internal.nix " ) ,
# include "primops/derivation.nix.gen.hh"
) }
, callFlakeInternal { internalFS - > addFile (
CanonPath ( " call-flake.nix " ) ,
# include "flake/call-flake.nix.gen.hh"
) }
Eliminate the "store" global variable
Also, move a few free-standing functions into StoreAPI and Derivation.
Also, introduce a non-nullable smart pointer, ref<T>, which is just a
wrapper around std::shared_ptr ensuring that the pointer is never
null. (For reference-counted values, this is better than passing a
"T&", because the latter doesn't maintain the refcount. Usually, the
caller will have a shared_ptr keeping the value alive, but that's not
always the case, e.g., when passing a reference to a std::thread via
std::bind.)
2016-02-04 15:28:26 +02:00
, 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-02-15 18:49:25 +02:00
, debugQuit ( 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 ) )
2022-01-22 22:17:35 +02:00
# endif
2010-04-14 17:42:32 +03:00
, baseEnv ( allocEnv ( 128 ) )
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
2015-03-19 21:02:37 +02:00
assert ( gcInitialised ) ;
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
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
vEmptyList . mkList ( 0 ) ;
2011-08-06 19:05:24 +03:00
/* Initialise the Nix expression search path. */
2018-03-27 20:02:22 +03:00
if ( ! evalSettings . pureEval ) {
2023-06-23 20:51:25 +03:00
for ( auto & i : _searchPath . elements )
2023-08-16 19:04:15 +03:00
searchPath . elements . emplace_back ( SearchPath : : Elem { i } ) ;
2023-06-23 20:51:25 +03:00
for ( auto & i : evalSettings . nixPath . get ( ) )
2023-08-16 19:04:15 +03:00
searchPath . elements . emplace_back ( SearchPath : : 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. */
2023-11-30 22:54:53 +02:00
if ( rootFS . dynamic_pointer_cast < AllowListInputAccessor > ( ) )
2023-11-30 17:16:17 +02:00
for ( auto & i : searchPath . elements )
resolveSearchPathPath ( 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 )
{
2023-11-30 22:54:53 +02:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListInputAccessor > ( ) )
rootFS2 - > allowPath ( CanonPath ( path ) ) ;
2021-10-07 13:11:00 +03:00
}
2021-10-07 15:07:51 +03:00
void EvalState : : allowPath ( const StorePath & storePath )
{
2023-11-30 22:54:53 +02:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListInputAccessor > ( ) )
rootFS2 - > allowPath ( 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 )
{
if ( ! evalSettings . restrictEval ) return ;
if ( isAllowedURI ( uri , evalSettings . 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 , " / " ) ) {
2023-11-30 22:54:53 +02:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListInputAccessor > ( ) )
rootFS2 - > checkAccess ( CanonPath ( uri ) ) ;
2018-02-06 15:35:14 +02:00
return ;
}
if ( hasPrefix ( uri , " file:// " ) ) {
2023-11-30 22:54:53 +02:00
if ( auto rootFS2 = rootFS . dynamic_pointer_cast < AllowListInputAccessor > ( ) )
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
2023-05-13 20:52:45 +03:00
if ( ! ( evalSettings . pureEval & & info . impureOnly ) ) {
/* 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 ;
baseEnv . values [ 0 ] - > attrs - > push_back ( Attr ( symbols . create ( name2 ) , v ) ) ;
}
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 ) ;
}
}
2023-12-12 23:57:36 +02:00
std : : ostream & operator < < ( std : : ostream & output , PrimOp & primOp )
{
output < < " primop " < < primOp . name ;
return output ;
}
PrimOp * Value : : primOpAppPrimOp ( ) const
{
Value * left = primOpApp . left ;
while ( left & & ! left - > isPrimOp ( ) ) {
left = left - > primOpApp . left ;
}
if ( ! left )
return nullptr ;
return left - > primOp ;
}
2023-11-16 12:10:25 +02:00
void Value : : mkPrimOp ( PrimOp * p )
{
p - > check ( ) ;
clearValue ( ) ;
internalType = tPrimOp ;
primOp = p ;
}
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 ;
2022-03-05 20:26:36 +02:00
baseEnv . values [ 0 ] - > 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
{
2016-08-23 18:11:19 +03: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 ;
2023-05-13 20:52:45 +03: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 = { } ,
2020-08-25 14:31:11 +03: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
} ;
}
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 ;
2022-03-31 18:37:36 +03:00
Bindings : : iterator 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.
Bindings : : iterator j = env . values [ 0 ] - > attrs - > begin ( ) ;
while ( j ! = env . values [ 0 ] - > attrs - > end ( ) ) {
vm [ st [ j - > name ] ] = j - > value ;
+ + j ;
}
} else {
// iterate through staticenv bindings and add them.
for ( auto & i : se . vars )
vm [ st [ i . first ] ] = env . values [ i . second ] ;
}
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 ;
}
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
{
2022-05-23 06:45:24 +03:00
// double check we've got the debugRepl function pointer.
2022-05-20 19:33:50 +03:00
if ( ! debugRepl )
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 ) ;
2022-05-25 19:21:20 +03:00
( debugRepl ) ( ref < EvalState > ( shared_from_this ( ) ) , * vm ) ;
2022-05-20 02:01:23 +03:00
}
}
2022-03-07 22:02:17 +02:00
void EvalState : : addErrorTrace ( Error & e , const char * s , const std : : string & s2 ) const
2007-02-27 21:10:45 +02:00
{
2022-12-13 01:48:04 +02:00
e . addTrace ( nullptr , s , s2 ) ;
2007-02-27 21:10:45 +02:00
}
2023-01-19 14:23:04 +02:00
void EvalState : : addErrorTrace ( Error & e , const PosIdx pos , const char * s , const std : : string & s2 , bool frame ) const
2013-11-12 13:51:59 +02:00
{
2024-02-04 06:35:19 +02:00
e . addTrace ( positions [ pos ] , HintFmt ( s , s2 ) , frame ) ;
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
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
static void copyContextToValue ( Value & v , 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 ;
2010-10-28 15:50:01 +03:00
v . string . context = ( 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 )
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
v . string . context [ n + + ] = dupString ( i . to_string ( ) . c_str ( ) ) ;
2010-03-31 22:52:29 +03:00
v . string . context [ n ] = 0 ;
}
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
{
mkString ( s ) ;
copyContextToValue ( * this , context ) ;
}
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
{
2021-12-27 03:04:49 +02:00
mkString ( s ) ;
copyContextToValue ( * this , context ) ;
}
2010-03-30 21:05:54 +03: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 " ) ;
2013-07-31 13:44:21 +03:00
Bindings : : iterator j = env - > values [ 0 ] - > attrs - > find ( var . name ) ;
if ( j ! = env - > values [ 0 ] - > attrs - > end ( ) ) {
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
}
2018-05-02 14:56:34 +03:00
void EvalState : : mkList ( Value & v , size_t size )
2010-03-30 17:39:27 +03:00
{
2020-12-18 15:38:49 +02:00
v . mkList ( size ) ;
if ( size > 2 )
v . bigList . elems = ( Value * * ) allocBytes ( size * sizeof ( Value * ) ) ;
2015-07-23 23:05:09 +03:00
nrListElems + = size ;
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
{
2022-03-04 20:31:59 +02:00
auto pos = positions [ p ] ;
2023-04-06 16:25:06 +03:00
if ( auto path = std : : get_if < SourcePath > ( & pos . 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 ( ) ) ;
2022-03-04 20:31:59 +02:00
attrs . alloc ( sLine ) . mkInt ( pos . line ) ;
attrs . alloc ( sColumn ) . mkInt ( pos . column ) ;
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
fileParseCache [ 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
2021-09-13 15:41:28 +03:00
fileEvalCache [ resolvedPath ] = v ;
if ( path ! = resolvedPath ) fileEvalCache [ 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 ( ) ;
2023-01-19 14:23:04 +02:00
return v . boolean ;
} 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 )
{
abort ( ) ;
}
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
}
void ExprAttrs : : eval ( EvalState & state , Env & env , Value & v )
{
2022-01-04 21:29:17 +02:00
v . mkAttrs ( state . buildBindings ( attrs . size ( ) + dynamicAttrs . size ( ) ) . finish ( ) ) ;
auto dynamicEnv = & env ;
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 ;
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-01-27 17:33:34 +02:00
if ( hasOverrides & & ! i . second . 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 , & env2 ) , 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 , & env2 ) ) ;
2013-07-16 00:10:18 +03:00
env2 . values [ displ + + ] = vAttr ;
2022-03-04 20:31:59 +02:00
v . attrs - > push_back ( Attr ( 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 ) {
Value * vOverrides = ( * v . attrs ) [ overrides - > second . displ ] . value ;
2023-01-19 14:23:04 +02:00
state . forceAttrs ( * vOverrides , [ & ] ( ) { return vOverrides - > determinePos ( noPos ) ; } , " while evaluating the `__overrides` attribute " ) ;
2019-11-25 14:37:14 +02:00
Bindings * newBnds = state . allocBindings ( v . attrs - > capacity ( ) + vOverrides - > attrs - > size ( ) ) ;
2014-09-19 17:49:41 +03:00
for ( auto & i : * v . attrs )
newBnds - > push_back ( i ) ;
for ( auto & i : * vOverrides - > attrs ) {
AttrDefs : : iterator j = attrs . find ( i . name ) ;
2010-10-24 22:52:33 +03:00
if ( j ! = attrs . end ( ) ) {
2014-09-19 17:49:41 +03:00
( * newBnds ) [ j - > second . displ ] = i ;
env2 . values [ j - > second . displ ] = i . value ;
2010-10-24 22:52:33 +03:00
} else
2014-09-19 17:49:41 +03:00
newBnds - > push_back ( i ) ;
2010-05-15 11:10:12 +03:00
}
2014-09-19 17:49:41 +03:00
newBnds - > sort ( ) ;
v . attrs = newBnds ;
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 {
for ( auto & i : attrs ) {
v . attrs - > push_back ( Attr (
i . first ,
i . second . e - > maybeThunk ( state , * i . second . chooseByKind ( & env , & env , & env ) ) ,
i . second . pos ) ) ;
}
}
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 ( ) ) ;
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
Bindings : : iterator j = v . attrs - > find ( nameSym ) ;
if ( j ! = 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
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 */
2022-03-04 20:31:59 +02:00
v . attrs - > push_back ( Attr ( nameSym , i . valueExpr - > maybeThunk ( state , * dynamicEnv ) , i . pos ) ) ;
2014-09-19 17:49:41 +03:00
v . attrs - > sort ( ) ; // FIXME: inefficient
2010-04-12 21:30:11 +03:00
}
2021-01-08 23:27:00 +02:00
2022-03-04 20:31:59 +02:00
v . attrs - > pos = pos ;
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
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 ,
* i . second . chooseByKind ( & env2 , & env , & env2 ) ) ;
}
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 )
{
state . mkList ( v , elems . size ( ) ) ;
2021-11-24 21:21:34 +02:00
for ( auto [ n , v2 ] : enumerate ( v . listItems ( ) ) )
const_cast < Value * & > ( v2 ) = elems [ n ] - > maybeThunk ( state , env ) ;
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 ,
state . positions [ pos2 ] ,
" 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 + + ;
2011-07-06 15:28:57 +03:00
Bindings : : iterator 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 | |
2014-01-01 01:56:26 +02:00
( j = vAttrs - > attrs - > find ( name ) ) = = vAttrs - > attrs - > end ( ) )
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 " ) ;
2022-03-08 07:16:51 +02:00
if ( ( j = vAttrs - > attrs - > find ( name ) ) = = vAttrs - > attrs - > end ( ) ) {
std : : set < std : : string > allAttrNames ;
for ( auto & attr : * vAttrs - > attrs )
2022-03-05 15:40:24 +02:00
allAttrNames . insert ( 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
}
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 ( ) ) ;
2011-07-06 13:58:17 +03:00
Bindings : : iterator j ;
2022-03-05 15:40:24 +02:00
auto name = getName ( i , state , env ) ;
2020-12-17 15:45:45 +02:00
if ( vAttrs - > type ( ) ! = nAttrs | |
2014-01-01 01:56:26 +02:00
( j = vAttrs - > attrs - > find ( name ) ) = = vAttrs - > attrs - > end ( ) )
2011-07-06 13:58:17 +03:00
{
2022-01-04 19:40:39 +02:00
v . mkBool ( false ) ;
2011-07-06 13:58:17 +03:00
return ;
} else {
vAttrs = j - > value ;
}
}
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
{
2023-12-15 21:52:21 +02:00
if ( callDepth > evalSettings . 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 ) ;
2022-03-04 20:31:59 +02:00
auto trace = evalSettings . traceFunctionCalls
? 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
2021-11-16 18:44:19 +02:00
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
2020-02-24 02:32:01 +02:00
ExprLambda & lambda ( * vCur . 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 ) ) ;
env2 . up = vCur . 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 ) {
auto j = args [ 0 ] - > attrs - > get ( i . name ) ;
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 " )
. withFrame ( * fun . 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 ` . . . ' ) . */
if ( ! lambda . formals - > ellipsis & & attrsUsed ! = args [ 0 ] - > attrs - > size ( ) ) {
/* Nope, so show the first unexpected argument to the
user . */
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 )
2022-03-05 15:40:24 +02:00
formalNames . insert ( 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 )
. withFrame ( * fun . 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
}
2020-02-24 02:32:01 +02:00
abort ( ) ; // can't happen
}
}
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 ] , " ' " )
: " anonymous lambda " ,
true ) ;
if ( pos ) addErrorTrace ( e , pos , " from call site%s " , " " , true ) ;
2020-02-24 02:32:01 +02:00
}
throw ;
}
nrArgs - - ;
args + = 1 ;
}
else if ( vCur . isPrimOp ( ) ) {
size_t argsLeft = vCur . primOp - > arity ;
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. */
2023-12-10 09:24:45 +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 ) {
2023-12-11 17:23:08 +02:00
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 + + ;
primOp = primOp - > primOpApp . left ;
}
assert ( primOp - > isPrimOp ( ) ) ;
auto arity = primOp - > primOp - > arity ;
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 ;
for ( Value * arg = & vCur ; arg - > isPrimOpApp ( ) ; arg = arg - > primOpApp . left )
vArgs [ - - n ] = arg - > primOpApp . right ;
for ( size_t i = 0 ; i < argsLeft ; + + i )
vArgs [ argsDone + i ] = args [ i ] ;
2023-12-10 09:24:45 +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 ) {
2023-12-11 17:23:08 +02:00
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
2021-11-16 18:44:19 +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 ) {
2015-11-25 18:56:14 +02:00
auto found = fun . attrs - > find ( sFunctor ) ;
if ( found ! = fun . attrs - > end ( ) ) {
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 ) ;
}
}
2021-10-06 18:08:08 +03:00
if ( ! fun . isLambda ( ) | | ! fun . lambda . fun - > hasFormals ( ) ) {
2010-04-07 18:47:06 +03:00
res = fun ;
return ;
}
2022-01-04 18:39:16 +02:00
auto attrs = buildBindings ( std : : max ( static_cast < uint32_t > ( fun . lambda . fun - > formals - > formals . size ( ) ) , args . size ( ) ) ) ;
2010-04-12 21:30:11 +03:00
2020-08-27 19:28:12 +03:00
if ( fun . lambda . fun - > formals - > ellipsis ) {
// 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
for ( auto & i : fun . lambda . fun - > formals - > formals ) {
Bindings : : iterator j = args . find ( i . name ) ;
if ( j ! = args . end ( ) ) {
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])
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
. atPos ( i . pos ) . withFrame ( * fun . lambda . env , * fun . 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 " ) ) {
2020-01-11 16:06:57 +02:00
std : : ostringstream out ;
2022-03-05 15:40:24 +02:00
cond - > show ( state . symbols , out ) ;
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
state . error < AssertionError > ( " assertion '%1%' failed " , out . str ( ) ) . 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 + + ;
2010-08-02 19:31:05 +03:00
if ( v1 . attrs - > size ( ) = = 0 ) { v = v2 ; return ; }
if ( v2 . attrs - > size ( ) = = 0 ) { v = v1 ; return ; }
2022-01-04 21:29:17 +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 . */
2010-10-24 22:52:33 +03:00
Bindings : : iterator i = v1 . attrs - > begin ( ) ;
Bindings : : iterator j = v2 . attrs - > begin ( ) ;
2010-08-02 19:31:05 +03:00
2010-10-24 22:52:33 +03:00
while ( i ! = v1 . attrs - > end ( ) & & j ! = v2 . attrs - > end ( ) ) {
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
2022-01-04 21:29:17 +02:00
while ( i ! = v1 . attrs - > end ( ) ) attrs . insert ( * i + + ) ;
while ( j ! = v2 . attrs - > end ( ) ) attrs . insert ( * j + + ) ;
v . mkAttrs ( attrs . alreadySorted ( ) ) ;
2013-09-02 17:29:15 +03:00
2010-10-20 18:48:00 +03: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
}
2023-01-19 14:23:04 +02:00
void EvalState : : concatLists ( Value & v , size_t nrLists , Value * * 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
}
mkList ( v , len ) ;
2015-07-23 23:05:09 +03:00
auto out = v . listElems ( ) ;
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 ;
}
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 ;
2013-08-19 13:35:03 +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 ) {
2016-01-05 01:40:40 +02:00
n + = vTmp . integer ;
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 ;
2016-01-05 01:40:40 +02:00
nf = n ;
nf + = vTmp . fpoint ;
} 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 ) {
2016-01-05 01:40:40 +02:00
nf + = vTmp . integer ;
2020-12-17 15:45:45 +02:00
} else if ( vTmp . type ( ) = = nFloat ) {
2016-01-05 01:40:40 +02:00
nf + = vTmp . fpoint ;
} 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 ) {
2015-03-06 16:10:12 +02:00
for ( auto & i : * v . attrs )
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 ( )
2022-05-15 21:05:51 +03:00
? makeDebugTraceStacker ( * this , * i . value - > thunk . expr , * i . value - > 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 ( ) ;
2023-01-19 14:23:04 +02:00
return v . integer ;
} 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
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 )
return v . integer ;
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 ( ) ;
2023-01-19 14:23:04 +02:00
return v . fpoint ;
} 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 ( ) ;
2023-01-19 14:23:04 +02:00
return v . boolean ;
} 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
return v . boolean ;
2010-03-31 18:38:03 +03:00
}
2015-10-08 14:22:11 +03:00
bool EvalState : : isFunctor ( Value & fun )
{
2020-12-17 15:45:45 +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
{
2010-04-09 15:00:49 +03:00
if ( v . string . context )
2013-09-02 17:29:15 +03:00
for ( const char * * p = v . 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 ;
2010-04-13 15:25:42 +03:00
Bindings : : iterator i = v . attrs - > find ( sType ) ;
2011-10-27 22:06:23 +03:00
if ( i = = v . attrs - > end ( ) ) 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
{
auto i = v . attrs - > find ( sToString ) ;
if ( i ! = v . attrs - > end ( ) ) {
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}.
2023-10-18 16:32:31 +03:00
v . _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 ) ;
2019-10-27 11:15:51 +02:00
auto i = v . attrs - > find ( sOutPath ) ;
2022-11-29 01:25:36 +02:00
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 {
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
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 ' . */
2020-12-17 15:45:45 +02:00
if ( v . type ( ) = = nBool & & v . boolean ) return " 1 " ;
if ( v . type ( ) = = nBool & & ! v . boolean ) return " " ;
if ( v . type ( ) = = nInt ) return std : : to_string ( v . integer ) ;
if ( v . type ( ) = = nFloat ) return std : : to_string ( v . fpoint ) ;
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
2023-04-06 14:15:50 +03:00
auto i = srcToStore . find ( path ) ;
auto dstPath = i ! = srcToStore . end ( )
? i - > second
: [ & ] ( ) {
2024-01-30 16:00:18 +02:00
auto dstPath = fetchToStore ( * store , path . resolveSymlinks ( ) , path . baseName ( ) , FileIngestionMethod : : Recursive , nullptr , repair ) ;
2023-04-06 14:15:50 +03:00
allowPath ( dstPath ) ;
srcToStore . insert_or_assign ( path , dstPath ) ;
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 ) {
2023-10-20 14:04:39 +03:00
auto i = v . attrs - > find ( sToString ) ;
if ( i ! = v . attrs - > end ( ) ) {
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 ;
}
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 )
2016-01-05 01:40:40 +02:00
return v1 . integer = = v2 . fpoint ;
2020-12-17 15:45:45 +02:00
if ( v1 . type ( ) = = nFloat & & v2 . type ( ) = = nInt )
2016-01-05 01:40:40 +02:00
return v1 . fpoint = = v2 . integer ;
// 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 :
2010-03-29 17:37:56 +03:00
return v1 . integer = = v2 . integer ;
2020-12-12 03:09:10 +02:00
case nBool :
2010-03-29 17:37:56 +03:00
return v1 . boolean = = v2 . boolean ;
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.
2023-10-18 16:32:31 +03:00
v1 . _path . accessor = = v2 . _path . accessor
& & strcmp ( v1 . _path . path , v2 . _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 ) ) {
Bindings : : iterator i = v1 . attrs - > find ( sOutPath ) ;
Bindings : : iterator j = v2 . attrs - > find ( sOutPath ) ;
if ( i ! = v1 . attrs - > end ( ) & & j ! = v2 . attrs - > end ( ) )
2023-01-19 14:23:04 +02:00
return eqValues ( * i - > value , * j - > value , pos , errorCtx ) ;
2012-01-20 01:08:47 +02:00
}
2010-04-16 16:51:01 +03: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. */
Bindings : : 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 :
2014-11-30 20:16:19 +02:00
return * v1 . external = = * v2 . external ;
2020-12-12 03:09:10 +02:00
case nFloat :
2016-01-05 01:40:40 +02:00
return v1 . fpoint = = v2 . fpoint ;
2023-04-03 19:03:20 +03:00
case nThunk : // Must not be left by forceValue
2010-03-29 17:37:56 +03:00
default :
libexpr: Support structured error classes
While preparing PRs like #9753, I've had to change error messages in
dozens of code paths. It would be nice if instead of
EvalError("expected 'boolean' but found '%1%'", showType(v))
we could write
TypeError(v, "boolean")
or similar. Then, changing the error message could be a mechanical
refactor with the compiler pointing out places the constructor needs to
be changed, rather than the error-prone process of grepping through the
codebase. Structured errors would also help prevent the "same" error
from having multiple slightly different messages, and could be a first
step towards error codes / an error index.
This PR reworks the exception infrastructure in `libexpr` to
support exception types with different constructor signatures than
`BaseError`. Actually refactoring the exceptions to use structured data
will come in a future PR (this one is big enough already, as it has to
touch every exception in `libexpr`).
The core design is in `eval-error.hh`. Generally, errors like this:
state.error("'%s' is not a string", getAttrPathStr())
.debugThrow<TypeError>()
are transformed like this:
state.error<TypeError>("'%s' is not a string", getAttrPathStr())
.debugThrow()
The type annotation has moved from `ErrorBuilder::debugThrow` to
`EvalState::error`.
2024-01-23 03:08:29 +02:00
error < EvalError > ( " cannot compare %1% with %2% " , showType ( v1 ) , showType ( v2 ) ) . withTrace ( pos , errorCtx ) . debugThrow ( ) ;
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 ( )
{
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 ) ;
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 ) ;
# 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 ( ) ;
topObj [ " cpuTime " ] = cpuTime ;
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 } ,
} ;
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-01-15 17:52:18 +02:00
SourcePath resolveExprPath ( SourcePath path )
{
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-01-15 17:52:18 +02:00
if ( p . lstat ( ) . type ! = InputAccessor : : tSymlink ) break ;
path = { path . accessor , CanonPath ( p . readLink ( ) , path . path . parent ( ) . value_or ( CanonPath : : root ) ) } ;
}
/* If `path' refers to a directory, append `/default.nix'. */
if ( path . resolveSymlinks ( ) . lstat ( ) . type = = InputAccessor : : 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 )
{
auto s = make_ref < std : : string > ( std : : move ( s_ ) ) ;
s - > append ( " \0 \0 " , 2 ) ;
return parse ( s - > data ( ) , s - > size ( ) , Pos : : String { . source = s } , basePath , staticEnv ) ;
}
Expr * EvalState : : parseExprFromString ( std : : string s , const SourcePath & basePath )
{
return parseExprFromString ( std : : move ( s ) , basePath , staticBaseEnv ) ;
}
Expr * EvalState : : parseStdin ( )
{
//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 ) ;
auto s = make_ref < std : : string > ( std : : move ( buffer ) ) ;
return parse ( s - > data ( ) , s - > size ( ) , Pos : : Stdin { . source = s } , rootPath ( CanonPath : : fromCwd ( ) ) , staticBaseEnv ) ;
}
SourcePath EvalState : : findFile ( const std : : string_view path )
{
return findFile ( searchPath , path ) ;
}
SourcePath EvalState : : findFile ( const SearchPath & searchPath , const std : : string_view path , const PosIdx pos )
{
for ( auto & i : searchPath . elements ) {
auto suffixOpt = i . prefix . suffixIfPotentialMatch ( path ) ;
if ( ! suffixOpt ) continue ;
auto suffix = * suffixOpt ;
auto rOpt = resolveSearchPathPath ( i . path ) ;
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 > (
evalSettings . 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
}
std : : optional < std : : string > EvalState : : resolveSearchPathPath ( const SearchPath : : Path & value0 , bool initAccessControl )
{
auto & value = value0 . s ;
auto i = searchPathResolved . find ( value ) ;
if ( i ! = searchPathResolved . end ( ) ) return i - > second ;
std : : optional < std : : string > res ;
if ( EvalSettings : : isPseudoUrl ( value ) ) {
try {
auto storePath = fetchers : : downloadTarball (
store , EvalSettings : : resolvePseudoUrl ( value ) , " source " , false ) . storePath ;
res = { store - > toRealPath ( storePath ) } ;
} catch ( FileTransferError & e ) {
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
} ) ;
}
}
else if ( hasPrefix ( value , " flake: " ) ) {
experimentalFeatureSettings . require ( Xp : : Flakes ) ;
auto flakeRef = parseFlakeRef ( value . substr ( 6 ) , { } , true , false ) ;
debug ( " fetching flake search path element '%s'' " , value ) ;
auto storePath = flakeRef . resolve ( store ) . fetchTree ( store ) . first ;
res = { store - > toRealPath ( storePath ) } ;
}
else {
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 ) )
res = { path } ;
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
} ) ;
res = std : : nullopt ;
}
}
if ( res )
debug ( " resolved search path element '%s' to '%s' " , value , * res ) ;
else
debug ( " failed to resolve search path element '%s' " , value ) ;
searchPathResolved . emplace ( value , res ) ;
return res ;
}
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-01-15 17:52:18 +02:00
auto result = parseExprFromBuf ( text , length , origin , basePath , symbols , positions , rootFS , exprSymbols ) ;
2024-01-15 17:52:18 +02:00
result - > bindVars ( * this , staticEnv ) ;
return result ;
}
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
}
2014-12-02 17:02:03 +02:00
bool ExternalValueBase : : operator = = ( const ExternalValueBase & b ) const
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
}