| Age | Commit message (Collapse) | Author |
|---|
|
|
|
validPathInfo-ca-proper-datatype
|
|
|
|
|
|
|
|
validPathInfo-ca-proper-datatype
|
|
|
|
The idea is it's always more flexible to consumer a `Source` than a
plain string, and it might even reduce memory consumption.
I also looked at `addToStoreFromDump` with its `// FIXME: remove?`, but
the worked needed for that is far more up for interpretation, so I
punted for now.
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 8f41847394524fcac40d3b5620139ca7e94a18e3)
|
|
|
|
This does a few enums; the rest will be gotten in subsequent commits.
|
|
Most functions now take a StorePath argument rather than a Path (which
is just an alias for std::string). The StorePath constructor ensures
that the path is syntactically correct (i.e. it looks like
<store-dir>/<base32-hash>-<name>). Similarly, functions like
buildPaths() now take a StorePathWithOutputs, rather than abusing Path
by adding a '!<outputs>' suffix.
Note that the StorePath type is implemented in Rust. This involves
some hackery to allow Rust values to be used directly in C++, via a
helper type whose destructor calls the Rust type's drop()
function. The main issue is the dynamic nature of C++ move semantics:
after we have moved a Rust value, we should not call the drop function
on the original value. So when we move a value, we set the original
value to bitwise zero, and the destructor only calls drop() if the
value is not bitwise zero. This should be sufficient for most types.
Also lots of minor cleanups to the C++ API to make it more modern
(e.g. using std::optional and std::string_view in some places).
|
|
(cherry picked from commit a0de58f471c9087d8e6cc60a6078f9940a125b15)
|
|
|
|
|
