this needs a string comparison because there seems to be no other way to
get that information out of bison. usually the location info is going to
be correct (pointing at a bad token), but since EOF isn't a token as
such it'll be wrong in that this case.
this hasn't shown up much so far because a single line ending *is* a
token, so any file formatted in the usual manner (ie, ending in a line
ending) would have its EOF position reported correctly.
(cherry picked from commit 855fd5a1bb781e4f722c1d757ba43e866d370132)
Change-Id: I120c56a962f4286b1ae3b71da7b71ce8ec3e0535
the parser treats a plain \r as a newline, error reports do not. this
can lead to interesting divergences if anything makes use of this
feature, with error reports pointing to wrong locations in the input (or
even outside the input altogether).
(cherry picked from commit 2be6b143289e5479cc4a2667bb84e879116c2447)
Change-Id: Ieb7f7655bac8cb0cf5734c60bd41723388f2973c
previously we reported the error at the beginning of the binding
block (for plain inherits) or the beginning of the attr list (for
inherit-from), effectively hiding where exactly the error happened.
this also carries over to runtime positions of attributes in sets as
reported by unsafeGetAttrPos. we're not worried about this changing
observable eval behavior because it *is* marked unsafe, and the new
behavior is much more useful.
(cherry picked from commit 1edd6fada53553b89847ac3981ac28025857ca02)
Change-Id: I2f50eb9f3dc3977db4eb3e3da96f1cb37ccd5174
we already normalize attr order to lexicographic, doing the same for
formals makes sense. doubly so because the order of formals would
otherwise depend on the context of the expression, which is not quite as
useful as one might expect.
(cherry picked from commit 4147ecfb1c51f3fe3b4adcbd4e753fd487dab645)
Change-Id: I3fd0dbdef3ac7447a3a03ff20bb514a0d0f23fb1
the parser modifies its inputs, which means that sharing them between
the error context reporting system and the parser itself can confuse the
reporting system. usually this led to early truncation of error context
reports which, while not dangerous, can be quite confusing.
(cherry picked from commit d384ecd553aa997270b79ee98d02f7cf7e1849e6)
Change-Id: I677646b5675b12b2faa787943646aa36dc6e6ee3
vfork confers a large performance advantage over fork, measured locally
at 16µs per vfork agains 90µs per fork. however nix *almost always*
follows a vfork up with an execve-family call, melting the performance
advantage from 6x to only 15%. in most of those cases it's doing things
that are undefined behavior (like manipulating the heap, or even
throwing exceptions and trashing the parent process stack).
most notably the one place that could benefit from the vfork performance
improvement is linux derivation sandbox setup—which doesn't use vfork.
Change-Id: I2037b7384d5a4ca24da219a569e1b1f39531410e
This builtin is only going to cause us problems because we are not Nix,
so let's just falsify being in the 2.18 series, since that is the
closest target that has any meaning.
In future we might want to have a better feature detection mechanism,
for when we actually add stuff to some builtin's attr set argument. But
builtins.nixVersion is just going to be hopelessly broken and it should
be stubbed out.
Fixes lix-project/lix#144
Change-Id: Id7390b32a29c6147f2977737d81846320de5d67e
diagnose attr duplication at the path the duplication was detected, not
at the path the current attribute wanted to place. doing the latter is
only correct if a leaf attribute was duplicated, not if an attrpath was
set to a non-attrset in one binding and a (potentially implied) attrset
in another binding.
fixes#124
Change-Id: Ic4aa9cc12a9874d4e7897c6f64408f10aa36fc82
-O3 does not measurably improve performance of the resulting binaries,
neither with lto enabled nor with lto disabled. what it does to however
is cause gcc warning spew in libstdc++ that we can't do anything
about (and that upon inspection of libstdc++ source looks like a gcc
bug).
with lto, -O3:
Benchmark 1: GC_INITIAL_HEAP_SIZE=10g nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 4.608 s ± 0.027 s [User: 3.866 s, System: 0.522 s]
Range (min … max): 4.579 s … 4.640 s 10 runs
Benchmark 2: nix eval -f <nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix>
Time (mean ± σ): 408.1 ms ± 25.5 ms [User: 360.0 ms, System: 28.1 ms]
Range (min … max): 387.6 ms … 439.0 ms 10 runs
with lto, -O2:
Benchmark 1: GC_INITIAL_HEAP_SIZE=10g nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 4.632 s ± 0.044 s [User: 3.874 s, System: 0.544 s]
Range (min … max): 4.563 s … 4.673 s 10 runs
Benchmark 2: nix eval -f <nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix>
Time (mean ± σ): 394.0 ms ± 23.9 ms [User: 351.2 ms, System: 27.6 ms]
Range (min … max): 377.8 ms … 429.3 ms 10 runs
without lto, -O3:
Benchmark 1: GC_INITIAL_HEAP_SIZE=10g nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 4.700 s ± 0.024 s [User: 3.906 s, System: 0.559 s]
Range (min … max): 4.663 s … 4.717 s 10 runs
Benchmark 2: nix eval -f <nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix>
Time (mean ± σ): 400.4 ms ± 25.6 ms [User: 353.7 ms, System: 26.8 ms]
Range (min … max): 379.8 ms … 430.6 ms 10 runs
without lto, -O2:
Benchmark 1: GC_INITIAL_HEAP_SIZE=10g nix eval --raw --impure --expr 'with import <nixpkgs/nixos> {}; system'
Time (mean ± σ): 4.724 s ± 0.030 s [User: 3.924 s, System: 0.570 s]
Range (min … max): 4.687 s … 4.749 s 10 runs
Benchmark 2: nix eval -f <nixpkgs/pkgs/development/haskell-modules/hackage-packages.nix>
Time (mean ± σ): 392.4 ms ± 24.3 ms [User: 350.9 ms, System: 26.4 ms]
Range (min … max): 376.9 ms … 428.0 ms 10 runs
fixes#46
Change-Id: Ib8afad8a07c278f57f2e3317d00cce4f9ec0f338
It happens with some frequency that plugins that might be unimportant to
the evaluation at hand mismatch with the nix version, leading to
spurious load failures. Let's make these non fatal.
Change-Id: Iba10e951d171725ccf1a121bcd9be1e1d6ad69eb
This is because they are unrepresentable in the source files with
commentary but not in the output, so we should just eat them in
normalization. It's ok.
Change-Id: I2cb7e8b3fc7b00874885bb287cbaa200b41cb16b
`macOS` does not have `glibcLocales`:
error:
… while calling the 'derivationStrict' builtin
at /derivation-internal.nix:9:12:
8|
9| strict = derivationStrict drvAttrs;
| ^
10|
… while evaluating derivation 'nix-2.90.0'
whose name attribute is located at /nix/store/y0c95bwyvs80pm69hdd4b11pyq2ghiwh-source
/pkgs/stdenv/generic/make-derivation.nix:348:7
… while evaluating attribute 'LOCALE_ARCHIVE' of derivation 'nix-2.90.0'
at /nix/store/ng5qzbyv4902b4pw7g35caqw5cnmryf9-source/flake.nix:331:15:
330| # Required to make non-NixOS Linux not complain about missing loc
Change-Id: I4464484a0eca12b5e073d49d900b6f25886245c1
using the total-attrs-printed and total-list-items-printed counters to
calculate how many attrs were elided only works properly if no nesting
is involved. once things do nest the global counter can exceed the size
of the currently printed object, leading to unsigned wrapping and great
overestimation of elided counts. counting locally in addition to global
counts fixes this.
these are functional tests because creating these objects requires the
evaluator to not be a huge amount of code, and we also want defaults to
be tested for cli usage.
fixes#14
Change-Id: Icb9a0cb21b2f4bacbc5e9dcdd8c0b9055b4088a7
this lets us set per-test-program environment variables rather than only
a single, global default. this was supported in nix originally but
might've gone partially missing in the upstream backports process?
Change-Id: Iad0919841b1b6d11e0b7ebd3920449a62f544e77
This has some Flaws for sure (like, it is going to be a bit stretched to
use for repl characterization), but it is a start.
Change-Id: I258c8beb3aee236f45818a03be83bcda858120c9
This is definitely not a stable thing, but it does feel slightly crimes
to put it as an experimental feature. Shrug, up for bikeshedding.
Change-Id: I6ef176e3dee6fb1cac9c0a7a60d553a2c63ea728
* changes:
package: cleanup of all intermediaries
package: migrate devShells
package: migrate internal-api-docs
package: migrate testNixVersions
package: use pname, version, and dontBuild (first change with diff hash)
package: refactor Nix out of flake.nix and into package.nix
The src fileset, preConfigure, and separateDebugInfo also respond to doBuild if its overridden
This commit is logically just a continuation of the previous commit's
refactor, but exists separately to delineate when the core Nix
derivation hash changed (this commit).
Change-Id: I67a61bc9608d91b6a833ebc5c3894b2d2e694050
This series takes a somewhat different approach from the flake rework
done in NixOS/nix. The package.nix here does not provide callPackage
options for all the various settings in the build, and instead the other
places Nix derivations are used (like internal-api-docs) will .overrideAttrs
the normal Nix package derivation. This more closely matches how these
things were structured originally, and results in less churn and more
atomicity in these changes.
In the future, package.nix likely will migrate to have more build
options in the callPackage arguments, but we are also planning to
rewrite the build system anyway.
Change-Id: I170c4e5a4184bab62e1fd75e56db876d4ff116cf
eldritch horrors
jade
Qyriad
Rebecca Turner
puck