| Age | Commit message (Collapse) | Author |
|---|
|
This commit adds several meson.build, which successfully build and
install Lix executables, libraries, and headers. Meson does not yet
build docs, Perl bindings, or run tests, which will be added in
following commits. As such, this commit does not remove the existing
build system, or make it the default, and also as such, this commit has
several FIXMEs and TODOs as notes for what should be done before the
existing autoconf + make buildsystem can be removed and Meson made the
default. This commit does not modify any source files.
A Meson-enabled build is also added as a Hydra job, and to
`nix flake check`.
Change-Id: I667c8685b13b7bab91e281053f807a11616ae3d4
|
|
|
|
Change-Id: Iacac97de0b3d5f2df52c7bc985148624a351f45d
|
|
this was mostly an inconvenience for error reporting, but fully broke
the debugger (because the debugger does *a lot* of eager position
resolution). copying the line offsets into a local and filling that
local when empty without also storing the calculated offsets back does
kind of ... not cache anything.
fixes https://git.lix.systems/lix-project/lix/issues/165
Change-Id: Iccb0ba193ce2f15c832978daecf7b9bebbbe8585
|
|
|
|
within lix itself this problem is caught by the test suite. outside of
lix itself three cases can be had: either the problem is fully inside
lix libs, fully inside user code, or it exists at the boundary. the
first is caught by the test suite, the second isn't caught at all, and
the third is something lix should not be responsible for.
Change-Id: I95aa35d8cb6f0ef5816a2941c467bc0c15916063
|
|
* changes:
Release notes for builtins.nixVersion change
un-nixes ur lix, a little
issue importer: list issues that are *not* closed when finding existing issues
|
|
We do not need upstart, it is so thoroughly obsolete that we should not
care about supporting it.
Change-Id: Ie0ca084740845555fddffacc899cd129c9a4c1fe
|
|
Change-Id: I72c945cab464d26d73f5594ef0a4bb2184545da4
|
|
I didn't really go attack the docs because we need to pull a bunch of
PRs. I went looking for strings in the code that called lix nix.
Change-Id: I2138bb4dd239096bc530946b281db7f875195b39
|
|
Turns out also, you cannot set the queue to 0 with any success. So we
really should just like, prevent notifications in forgejo itself.
Filed a bug for that:
https://git.lix.systems/lix-project/web-services/issues/38
Change-Id: Ib96749f3159659182904963cab7b2ef88fc64442
|
|
This brings in infrastructure for developing new custom clang-tidy lints
and refactors for Lix.
Change-Id: I3df5f5855712ab4f97d4e84d771e5e818f81f881
|
|
add a reset() method to close the wrapped fd instead of assigning magic
constants. also make the from-fd constructor explicit so you can't
accidentally assign the *wrong* magic constant, or even an unrelated
integer that also just happens to be an fd by pure chance.
Change-Id: I51311b0f6e040240886b5103d39d1794a6acc325
|
|
|
|
static env association is from expr to its enclosing scope, but let
exprs set their association to their *inner* scope. this skips one level
of envs and will cause segfaults if the parent is a with expr.
fixes #145
Change-Id: I1d22146110f071ede21b4eed7ed34b5850ef2ef3
|
|
Contemplate the configuration with: https://clang-format-configurator.site/
(cherry picked from commit 53fdcbca509b6c5dacaea3d3c465d86e49b0dd74)
Change-Id: I5446fd45de2bf644e34112f719afb3318a440b30
|
|
not doing this exposes the binding name order to the annoying
interference of parse order on symbol order, which wouldn't be so bad if
it didn't make the tests less reliable and, importantly, dependent on
linker behavior (due to primop initialization being done in static
initializer, and the order of static initializers being defined only
within a single translation unit).
fixes #143
Change-Id: I3cf417893fbcf19e9ad3ff8986deb7cbcf3ca511
|
|
|
|
we now keep not a table of all positions, but a table of all origins and
their sizes. position indices are now direct pointers into the virtual
concatenation of all parsed contents. this slightly reduces memory usage
and time spent in the parser, at the cost of not being able to report
positions if the total input size exceeds 4GiB. this limit is not unique
to nix though, rustc and clang also limit their input to 4GiB (although
at least clang refuses to process inputs that are larger, we will not).
this new 4GiB limit probably will not cause any problems for quite a
while, all of nixpkgs together is less than 100MiB in size and already
needs over 700MiB of memory and multiple seconds just to parse. 4GiB
worth of input will easily take multiple minutes and over 30GiB of
memory without even evaluating anything. if problems *do* arise we can
probably recover the old table-based system by adding some tracking to
Pos::Origin (or increasing the size of PosIdx outright), but for time
being this looks like more complexity than it's worth.
since we now need to read the entire input again to determine the
line/column of a position we'll make unsafeGetAttrPos slightly lazy:
mostly the set it returns is only used to determine the file of origin
of an attribute, not its exact location. the thunks do not add
measurable runtime overhead.
notably this change is necessary to allow changing the parser since
apparently nothing supports nix's very idiosyncratic line ending choice
of "anything goes", making it very hard to calculate line/column
positions in the parser (while byte offsets are very easy).
(cherry picked from commit 5d9fdab3de0ee17c71369ad05806b9ea06dfceda)
Change-Id: Ie0b2430cb120c09097afa8c0101884d94f4bbf34
|
|
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
|
|
|
|
These now have equivalents in the standard lib in C++20. This change was
performed with a custom clang-tidy check which I will submit later.
Executed like so:
ninja -C build && run-clang-tidy -checks='-*,nix-*' -load=build/libnix-clang-tidy.so -p .. -fix ../tests | tee -a clang-tidy-result
Change-Id: I62679e315ff9e7ce72a40b91b79c3e9fc01b27e9
|
|
|
|
pkgs.pkgsStatic.glibcLocales is null, so the string coercion was failing
for devShells against static stdenvs
Change-Id: Iee8e1042a852133ce0432627d72a85e97c17055e
|
|
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 https://git.lix.systems/lix-project/lix/issues/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
|
|
We needed a script to go yoink all the real NixOS/Nix issues from our
mirror into the Lix repo.
Change-Id: If8c8ebfb58634c675eae450454c0189288c6b18a
|
|
|
|
-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
|
|
Change-Id: I4abc19029fb62712582761d4fc1895156b68803d
|
|
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
|
|
Change-Id: I97c00b5eb1288f68d8c2b484436cc185d040b8b2
|
|
Change-Id: I8b2d8211a24011fae1586a1182d7d0772a039cd7
|
|
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
|
|
Change-Id: Ib0591e1499c5dba5e5a83ee75a899c9d16986827
|
|
This allows for automating using the repl without needing a PTY, with
very easy to write test files.
Change-Id: Ia8d7854edd91f93477638942cb6fc261354e6035
|
|
This parser can be reused for other purposes. It's inspired by
https://bitheap.org/cram/
Although eelco's impostor exists https://github.com/mobusoperandi/eelco,
it is not very nice to depend on out of tree testing frameworks with no
way to customize them.
Change-Id: Ifca50177e09730182baf0ebf829c3505bbb0274a
|
|
(cherry-picked from commit ba0087316acc2aba999cabe5e1a159da636b2569)
Change-Id: I5a50afb3b7b65516df798ee51b74f06727a91928
|
|
`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
|
|
|
|
not complain" into main
|
|
|
|
We're not going to use it.
Fixes: #31
Change-Id: Ib17a2eb6cae1ecbbf9ad1062e576ba6107a3c13b
|
|
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
|
|
These are not the way that we want to do things.
Change-Id: I5f3706cf50d007a6659edb96a6230d52e18a769a
|
