unfortunately i have developed another theory
15
Replies
0
Boosts
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
This comment is unavailable — it may have been deleted or is not visible to you.
see the great thing about rust and specifically cargo, and the compiler being constructed in terms of its previous iteration, is that in order to use rust at all, you need to have the entire packaging ecosystem there with you on disk and in memory at all times
user matklad is also the one behind https://github.com/matklad/cargo-xtask/
his next TODO item from the earlier listing:
- reexport file crate API to make reading and wriing files easily
you might ask what API is that?
# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
#
# When uploading crates to the registry Cargo will automatically
# "normalize" Cargo.toml files for maximal compatibility
# with all versions of Cargo and also rewrite `path` dependencies
# to registry (e.g., crates.io) dependencies.
#
# If you are reading this file be aware that the original Cargo.toml
# will likely look very different (and much more reasonable).
# See Cargo.toml.orig for the original contents.
[package]
edition = "2024"
name = "file"
version = "0.1.1"
<--- varying --->
build = false
autolib = false
autobins = false
autoexamples = false
autotests = false
autobenches = false
<--- varying --->
description = "File abstractions for async runtimes"
readme = false
license = "MIT"
[lib]
name = "file"
path = "src/lib.rs"
[dependencies]
so rust has stepped up from git's abuse of SHA-1 alone. impressively, rust and git have stepped up to SHA-256 together
the least i could extract from this obviously absurd and excessively lengthy conversation: https://github.com/rust-lang/rfcs/pull/1133#issuecomment-161877620
the calculation of SHA-256 repeatedly at great length occurs frequently throughout cargo and rustc. this enables them to produce second-preimage collisions, i.e. fucking your shit all the way up
however, the rest revolves around these configurations:
(core ∧ ¬std)(core(¬float) ∧ ¬alloc)
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-164532576
To elaborate, the work beyond this RFC for that is
- Sign stdlib source code per stable compiler
- Teach stable rustc how to check to see if inputs match whitelist of signatures
- Cargoize the stdlib (we both already did that, right?)
- Teach Cargo how to find stdlib source per stable compiler including Cargofiles. Or just include source with stable compiler binary release
For those cross-compiling to a fixed few "conventional platforms", it may just be easier to download binaries for the foreign deps, or yes, even the rust libs too. I've argued against this in the RFC, thread, on IRC. But in hindsight, we really need not take an either-or approach. There is a "pure" subset of the standard library that Cargo was born knowing how to compile, and there is the whole extent which will always have some non-Rust deps (until somebody wants to support re-wrapping the the OS ABIs in pure Rust shims). I think it probably makes sense to keep this RFC focused on compiling the trivial subset since the two methodologies are indeed so different, but I'd be happy to help design/implement the binary download stuff too. Over time I still maintain the approaches can and should grow together, but to start it might be easiest to pursue both independently.
There is a "pure" subset of the standard library that Cargo was born knowing how to compile
consider this statement
Am I correct that as a side effect of this, cargo will learn to download sources of standard library crates? This will be super useful for IDE integration :)
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-214361711
@matkladYes it would, but only when it builds them from source as currently written. Of course, that can be changed however so it downloads it more often---that could be useful for overcoming the override limitations too.
By desugaring stdlib dependencies this early in the pipeline, we
are able to touch much less of Cargo. On the other hand, "stdlib"
is no longer a valid version for the purpose of [[replace]]-ing.
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-223746363
This isn't so bad, because one can still replace the dep the if one
knows the version number of the normally-resolved stdlib version.
More philosophically, replacements are done after solving version
requirements, at which point version requirements are gone and only
concrete resolved versions remain. "stdlib", in delegating the
choice of version elsewhere, is thus more of a version requirement
than version.
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-230950635
Cargo cannot express dependencies on "A compiler with support for X." This affects far more > than just the sysroot - every crate that uses a feature that went through stabilization post 1.0 should make use of such a thing. The sysroot getting a free pass on this papers over it just enough that it remains unfixed and painful for everyone else, IMO.
The sysroot uses unstable features internally, because it knows the rustc version it is built with. This is both a subset of the above, and hostile to independent compiler implementations. A principled solution to the above could easily encompass the unstable features used (heck, Cabal manages it!).
Not needing to recompile it for each crate. This is something that could be amply solved in the general case by Cargo keeping some global cache of built crates indexed by target, version, and features.
they mention cabal specifically and frequently. i suspect simon peyton-jones's involvement
The Rust Standard Library is indeed not well defined. It could be viewed as all rlibs (purposely exluding dylibs for rustc in this definition) distributed in the rust-std tarballs, or just those that form the reflexive-transitive closure of std
https://github.com/rust-lang/rfcs/pull/1133#issuecomment-231438919
Firstly, I don't think the Cargo.toml should have version = "stdlib" but rather the rust version they have today. That means there is no hope of the "real" version uniquely determining the version of the stdlib used.
So, we need Cargo to know that the version number is suspect---doesn't uniquely identify stdlib, and also that the source depends on the compiler.