| Age | Commit message (Collapse) | Author |
|---|
|
* some things that can throw are marked noexcept
yet the linter seems to think not. Maybe they can't throw in practice.
I would rather not have the UB possibility in pretty obvious cold
paths.
* various default-case-missing complaints
* a fair pile of casts from integer to character, which are in fact
deliberate.
* an instance of <https://clang.llvm.org/extra/clang-tidy/checks/bugprone/move-forwarding-reference.html>
* bugprone-not-null-terminated-result on handing a string to curl in
chunks of bytes. our usage is fine.
* reassigning a unique_ptr by CRIMES instead of using release(), then
using release() and ignoring the result. wild. let's use release() for
its intended purpose.
Change-Id: Ic3e7affef12383576213a8a7c8145c27e662513d
|
|
Remove warnings, small improvements
(cherry picked from commit 5ac87a75dd65c19c50976559a6f7810c315cd9d5)
Change-Id: I88349b6e954398dde83c845f42d41a9dd89ba9e0
|
|
Fix/remove some bad std::moves
(cherry picked from commit 8c049a9f044569ebda70231709f6f15d3073894a)
Change-Id: I720273378d2506a13883acee28abd096d099b0d4
|
|
Types converted:
- `NixStringContextElem`
- `OutputsSpec`
- `ExtendedOutputsSpec`
- `DerivationOutput`
- `DerivationType`
Existing ones mostly conforming the pattern cleaned up:
- `ContentAddressMethod`
- `ContentAddressWithReferences`
The `DerivationGoal::derivationType` field had a bogus initialization,
now caught, so I made it `std::optional`. I think #8829 can make it
non-optional again because it will ensure we always have the derivation
when we construct a `DerivationGoal`.
See that issue (#7479) for details on the general goal.
`git grep 'Raw::Raw'` indicates the two types I didn't yet convert
`DerivedPath` and `BuiltPath` (and their `Single` variants) . This is
because @roberth and I (can't find issue right now...) plan on reworking
them somewhat, so I didn't want to churn them more just yet.
Co-authored-by: Eelco Dolstra <edolstra@gmail.com>
|
|
Whereas `ContentAddressWithReferences` is a sum type complex because different
varieties support different notions of reference, and
`ContentAddressMethod` is a nested enum to support that,
`ContentAddress` can be a simple pair of a method and hash.
`ContentAddress` does not need to be a sum type on the outside because
the choice of method doesn't effect what type of hashes we can use.
Co-Authored-By: Cale Gibbard <cgibbard@gmail.com>
|
|
The `ContentAddressWithReferences` method is made total, with error
handling now squarely the caller's job. This is better.
|
|
|
|
In other words, use a plain `ContentAddress` not
`ContentAddressWithReferences` for `DerivationOutput::CAFixed`.
Supporting fixed output derivations with (fixed) references would be a
cool feature, but it is out of scope at this moment.
|
|
Good to round out the library interface.
|
|
I suppose we can use `dynamic-derivations` for the few things we neeed.
|
|
|
|
|
|
We weren't because this ancient PR predated it!
This is actually a new version of the pattern which addresses some
issues identified in #7479.
|
|
Also improve content-address.hh API docs.
|
|
|
|
|
|
This reverts commit ee9eb83a842eb97d0180fd9d349d30ff27fdb485.
|
|
With the switch to C++20, the rules became more strict, and we can no
longer initialize base classes. Make them comments instead.
(BTW
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2287r1.html
this offers some new syntax for this use-case. Hopefully this will be
adopted and we can eventually use it.)
|
|
Stuff crept in there.
|
|
|
|
This change can wait for another PR.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Inspired by https://github.com/NixOS/nix/pull/5599
|
|
|
|
|
|
I had started the trend of doing `std::visit` by value (because a type
error once mislead me into thinking that was the only form that
existed). While the optomizer in principle should be able to deal with
extra coppying or extra indirection once the lambdas inlined, sticking
with by reference is the conventional default. I hope this might even
improve performance.
|
|
|
|
In particular, this means that derivations can output derivations. But
that ramification isn't (yet!) useful as we would want, since there is
no way to have a dependent derivation that is itself a dependent
derivation.
|
|
|
|
|
|
Co-authored-by: John Ericson <git@JohnEricson.me>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
