Change-Id: I293f4e4c399c192b0fec30aa8554b64641eee0bf

Based off of https://github.com/NixOS/nix-eval-jobs/pull/332 and
9f292a402a6edf620b872bedaaad5f0a45c23826

closes https://git.lix.systems/lix-project/lix/issues/1214

Co-authored-by: Mic92 <joerg@thalheim.io>
Co-authored-by: Yannik Sander <yannik@floxdev.com>
Change-Id: Ifba7081b384d18fbdc47437de261d30b65a7930a

mimalloc is a compact general purpose allocator from Microsoft. It
consistently outperforms glibc's `malloc()` in allocation-heavy
workloads, such as Lix's evaluator

It's currently only linked in the main `nix` executable, as Boehm's GC
uses its own allocator. Other allocations that *do* go through glibc's
`malloc()` are still much faster, though

Benchmarked on x86_64-linux against Nixpkgs `bd07873`:

| attribute | thunks | lix@`1396012` | mimalloc | uplift |
|-------------------|---------|---------------|----------|--------|
| hello | 206444 | 0.726s | 0.620s | 1.17x |
| chromium | 1177382 | 2.273s | 2.136s | 1.06x |
| firefox-unwrapped | 1394797 | 2.521s | 2.378s | 1.06x |
| texliveFull | 3186440 | 4.992s | 4.672s | 1.07x |
| nixosTests.gnome | 7905808 | 6.115s | 5.723s | 1.07x |

Based-on: https://github.com/NixOS/nix/pull/15596
Co-authored-by: Bernardo Meurer Costa <beme@anthropic.com>
Change-Id: I3ad92eacc075efeaf3d9f7730ada7b29835536a4

Some issues are caused by users confused about their ambient search
paths, let's analyze the current configuration and make it awfully
obvious what is going on.

Towards #230.

Change-Id: I953ef3feaefc56cee68623c5aaa4d568ba1fd034
Signed-off-by: Raito Bezarius <raito@lix.systems>

We try to access to the Flake registry, if we are failing, it's hosed.
Otherwise, let's record some facts we can reuse later.

Towards #230.

Change-Id: I80dd8272d5c27f7f7ff01052e3487a0496ee29fc
Signed-off-by: Raito Bezarius <raito@lix.systems>

Based on `nix-info` and `nix --version` output.

Contributes towards #230.

Change-Id: I13bb9608b733e10037c6816456b5312e712c18ad
Signed-off-by: Raito Bezarius <raito@lix.systems>

Based on `nix-info` output and experience (LOCALE issues).

Change-Id: I350fff9592e7acc8fba0babe67c9fe1bf94a5781
Signed-off-by: Raito Bezarius <raito@lix.systems>

This is some code that is specific to systemd to fetch hostnamectl
information via the JSON flag.

This will be used for `nix doctor`.

Errors will show up similar to this:
```
❯ ./build/lix/nix/nix doctor
[INFO] Nix system type: 'x86_64-linux'
warning: could not get host information via hostnamectl: error: Expected JSON value to be of type 'string' but it is of type 'number'
```

and makes them non-fatal.

Change-Id: Idd39f29626e770b1cd3896e8eb8545416c74b041
Signed-off-by: Raito Bezarius <raito@lix.systems>

treating a file with an empty or zero hash as locked is not helpful.
these are placeholdes for "hash is not known", thus treating them as
a valid lock makes them completely useless (and confusing to users).

fixes #1233

Change-Id: If42b47281e6973fc86662b973db69e26f6346f5a

25.11 is dead, and so is mdbook 0.4

Also reenable linkcheck which was doing nothing this whole time lmao

Change-Id: I4a8b9c763b881de840d6ef1b1d85bf19941f4386

These uses of std::move are taking data out of a repeatedly-used state
object, à la Rust's std::mem::take(). But move-constructing or
move-assigning from an object does not guarantee that the moved-from
object is equivalent to a default-constructed one, or even that the
moved-from object will continue to function like a non-moved-from object
of that type (only that the object remains "valid").

Assuming there's no differing custom allocator shenanigans at play, both
libstdc++ and libc++ do leave moved-from std::map objects (and probably
others) in an empty, well-behaved, default-constructed state, at the
time of this writing. However the correct tool here is std::exchange().


Change-Id: I7cf76762a1b05a542b53fcd74be100646a6a6964

Change-Id: I74310683b6e721f3ad0a7b2e2e2aa28c6a6a6964

As part of efforts to make debugging our Curl usage easier


Change-Id: Ib1f8567daa8b3d3d559a164bc85a8b906a6a6964

As part of efforts to make debugging our Curl usage easier


Change-Id: I182bb3e968f1dfcd192ecd61103cba376a6a6964

As part of efforts to make debugging our Curl usage easier


Change-Id: Idb8c32b33b6bfd0eebb9c9fded7b251d6a6a6964

To avoid template instantiation problems during the incomming
extractions


Change-Id: Ia0179da00bdfa45034559be88a2b923c6a6a6964

Change-Id: If1a9c9d45e50af1d06d07a8510ab003e6a6a6964

This way, other parts of the codebase can use it.

Change-Id: I58673a6a56362692980426a6c8f70f5c6aff24d4
Signed-off-by: Raito Bezarius <raito@lix.systems>

Since d0190cff6f2314cc1c727ff113aea20e086f4bcc, the `justfile` uses
`$out` from the environment as an argument to `--prefix` in its `meson`
invocation.

The `$out` variable is... A bit spicy to use since its semantics change
depending on whether `nix develop` or `nix-shell` is used.

In a `nix develop` shell, a directory *relative to PWD* (and not
relative to the Nix expression) is exported. In a `nix-shell`, the
`$out` used comes from the derivation.

The alternative to this change is to make the `justfile` use a variable
name that would not conflict with a `nix-shell` and `nix develop` shell.
Since it wants to use that value for the `outdir` variable, this would
be the name I would pick first.

I chose to instead work around the issue within the `nix-shell` since
this would be breaking the existing interface. As tenuous as it is.

Change-Id: I64cd5fd85345457e14880cb133e9ddafd55a25da

rust-analyzer binaries that don't come from nix (such as the one
shipped with vscode's rust-analyzer extension by default) need the
`RUST_SRC_PATH` env var to be the path to rustc's sources, but this
wasn't set inside the devshell. this change explicitely adds it to
the environment. (trying to add pkgs.rustLibSrc and rustcSrc to
the shell's packages unfortunately does nothing, because they are
just pure source packages, nothing more.)

(the reason this probably didn't come up for other devs is because
1. a lot of lix devs use other editors that probably just use the
binary from the path, and the devshell installs pkgs.rust-analyzer,
which is patched to always have `RUST_SRC_PATH` set, and 2. because
pkgs.vscode-extensions.rust-lang.rust-analyzer is also patched to use
pkgs.rust-analyzer by default instead of the bundled one, so installing
the extension using nix instead of from the marketplace would also hide
this problem.)

Change-Id: Ia27daf2a88756311ac5485ea0af44aae242241a9