Before this change, expressions like:
with import <nixpkgs> {};
runCommand "foo" {} ''
echo '@nix {}' >&$NIX_LOG_FD
''
would result in Lix crashing, because accessing nonexistent fields of
a JSON object throws an exception.
Rather than handling each field individually, we just catch JSON
exceptions wholesale. Since these log messages are an unusual
circumstance, log a warning when this happens.
Fixes#544.
Change-Id: Idc2d8acf6e37046b3ec212f42e29269163dca893
(cherry picked from commit e55cd3beea710db727fd966f265a1b715b7285f3)
(cherry picked from commit ee03fd478e)
This was first tagged as 2.15.0, 1½ years ago; plenty of time for
everyone to catch up.
By now, the warning is causing more confusion than that it is helpful,
because passing a `.drv` or `drvPath` has legitimate use cases.
(cherry picked from commit f534a7a524)
This interferes with the progress bar, resulting in output like
evaluating derivation 'git+file:///home/eelco/Dev/nix-master#packages.x86_64-linux.default'/nix/store/zz8v96j5md952x0mxfix12xqnvq5qv5x-nix-2.26.0pre20241114_a95f6ea.drv
(cherry picked from commit 33a0fa882f)
It seems that I copied the expression for baseDir thoughtlessly and
did not come back to it.
- `baseDir` was only used in the `fromArgs` branch.
- `fromArgs` is true when `packages` is true.
(cherry picked from commit c4b95dbdd1)
In these trivial cases the final vector size (or lower bound on the size) is known,
so we can avoid some vector reallocations. This is not very important, but is just
good practice and general hygiene.
This is good practice to avoid pessimisations.
Left comments for the reasoning why ctors should be noexcept.
There are some tricky cases where we intentionally want throwing move ctors/assignments.
But those cases should really be reviewed, since some of those can be replaced
with more idiomatic copy/move-and-swap.
`auto &&` and `T &&` are forwarding references and can be
either lvalue or rvalue references. Moving from universal references
is incorrect and should not be done.
Moving from integral or floating-point values is pointless and just
worsens debug performance.
Naming class member variables the same as constructor arguments is a very
slippery slope because of how member variable names get resolved. Compiler
is not very helpful here and we need static analysis to forbid this kind of
stuff.
The following example illustrates the cause quite well:
```cpp
struct B {
B(int) {}
};
struct A {
A(int b): b([&](){
return b;
static_assert(std::is_same_v<decltype(b), int>);
}()) {
static_assert(std::is_same_v<decltype(b), int>);
}
void member() {
static_assert(std::is_same_v<decltype(b), B>);
}
B b;
};
int main() {
A(1).member();
}
```
From N4861 6.5.1 Unqualified name lookup:
> In all the cases listed in [basic.lookup.unqual], the scopes are searched
> for a declaration in the order listed in each of the respective categories;
> name lookup ends as soon as a declaration is found for the name.
> If no declaration is found, the program is ill-formed.
In the affected code there was a use-after-move for all accesses in the constructor
body, but this UB wasn't triggered.
These types of errors are trivial to catch via clang-tidy's [clang-analyzer-cplusplus.Move].
This may occur when stderr is a tty but stdin is empty.
E.g.
$ nix build </dev/null
error: unexpected EOF reading a line
These stdio handles are how some non-interactive sandboxes behave,
including the Nix build sandbox and Hercules CI Effects.
