I made a mistake merge. Reverting it in c778945806 undid the state
on master, but now I realize it crippled the git merge mechanism.
As the merge contained a mix of commits from `master..staging-next`
and other commits from `staging-next..staging`, it got the
`staging-next` branch into a state that was difficult to recover.
I reconstructed the "desired" state of staging-next tree by:
- checking out the last commit of the problematic range: 4effe769e2
- `git rebase -i --preserve-merges a8a018ddc0` - dropping the mistaken
merge commit and its revert from that range (while keeping
reapplication from 4effe769e2)
- merging the last unaffected staging-next commit (803ca85c20)
- fortunately no other commits have been pushed to staging-next yet
- applying a diff on staging-next to get it into that state
We expose it on the top level, but I don't think it makes sense to pull
it from a specific version of the rust tools when it is in fact version
agnostic.
This reverts a tiny portion of 912dca193a.
Due to a recent change in rustc 1.45.0, rustfmt now requires two
additional environment variables to be set in order to build
successfully: `CFG_RELEASE` and `CFG_RELEASE_CHANNEL`.
rls has racer baked in which needs to know where the rust source
is to be able to do completion for std libs. By default rls will use:
$(rustc --print sysroot)/lib/rustlib/src/rust/src
which is nonexistent, this commit sets the correct source path
in a same way like it's done in racer expression.
There are several tarballs (such as the `rust-lang/rust`-source) with a
`Cargo.toml` at root and several sub-packages (with their own Cargo.toml)
without using workspaces[1].
In such a case it's needed to move into a subdir to only build the
specified sub-package (e.g. `rustfmt` or `rsl`), however the artifacts
are at `/target` in the root-dir of the build environment. This breaks
the build since `buildRustPackage` searches for executables in `target`
(which is at the build-env's root) at the end of the `buildPhase`.
With the optional `buildAndTestSubdir`-argument, the builder moves into
the specified subdir using `pushd`/`popd` during `buildPhase` and
`checkPhase`.
Also moved the logic to find executables and libs to the end of the `buildPhase`
from a custom `postBuild`-hook to fix packages with custom `build`/`install`-procedures
such as `uutils-coreutils`.
[1] https://doc.rust-lang.org/book/ch14-03-cargo-workspaces.html
Kept 1.42 around for Thunderbird.
i686-apple-darwin is no longer supported upstream. We could still
support building it, for this one release, since we have the binary
for the previous release, (or bootstrap it for future releases from
Rust 1.42,) but since this release is the one that drops support, I
think it makes sense to do it now. (And probably nobody is using it
anyway.)
I find it extremely unlikely we'll ever package two different patch
versions of the same minor Rust version. New patch versions should
generally be compatible, so we shouldn't give people the expectation
they'll be able to pin to one. And by including the patch version in
the attribute name, we'd have to change the attribute every time a
patch version was released, which would unnecessarily create diff
noise and maintenance headaches for what should be a seamless upgrade.
The patch is included in rust master[1], but neither that, nor the
QuiltOS version we were using previously, apply to 1.42.0, so I've
included the fixed version here.
[1]: 4f15867faf
The Hydra build [1] failed because it was unable to link to `LLVM9`; add
`llvmShared` to `passthru` in order to stay up to date with required
LLVM versions. Also quote the homepage URLs, since that's preferred.
[1] https://hydra.nixos.org/build/112989779/nixlog/1
I thought about doing a seperate output for these, but they're tiny
compared to the size of the binary, so there's no point.
(cherry picked from commit 0489c1b4b2)
Cargo uses git-rs which is made to be built against the bundled libgit2
version that hasn't been part of a stable release yet. Using our libgit2
instead of the master version fails during runtime as they are not
compatible anymore.
After the next libgit2 update we can try again but it is likely that
there will also be yet another cargo release at that point in time…
This has several advantages:
1. It takes up less space on disk in-between builds in the nix store.
2. It uses less space in the binary cache for vendor derivation packages.
3. It uses less network traffic downloading from the binary cache.
4. It plays nicely with hashed mirrors like tarballs.nixos.org, which only
substitute --flat hashes on single files (not recursive directory hashes).
5. It's consistent with how simple `fetchurl` src derivations work.
6. It provides a stronger abstraction between input src-package and output
package, e.g., it's harder to accidentally depend on the src derivation at
runtime by referencing something like `${src}/etc/index.html`. Likewise, in
the store it's harder to get confused with something that is just there as a
build-time dependency vs. a runtime dependency, since the build-time
src dependencies are tarred up.
Disadvantages are:
1. It takes slightly longer to untar at the start of a build.
As currently implemented, this attaches the compacted vendor.tar.gz feature as a
rider on `verifyCargoDeps`, since both of them are relatively newly implemented
behavior that change the `cargoSha256`.
If this PR is accepted, I will push forward the remaining rust packages with a
series of treewide PRs to update the `cargoSha256`s.
This was only introduced in 1.40.0 and doesn't work on older versions.
thread 'main' panicked at 'Error: no rules matched rustc-dev.', src/bootstrap/builder.rs:231:21
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
failed to run: /build/rustc-1.38.0-src/build/bootstrap/debug/bootstrap dist rustc-dev
