Closed newpavlov closed 2 months ago
Some first notes before I can dig deeper:
first of all: when we have a list of crate names & exact versions, then we can totally trigger a rebuild for them.
For generating that list, our docs.rs database is not very well fitted. While we store the dependencies of each release, it's just a JSON blob so (right now) can't be queried efficiently.
So for generating that list we would probably look at the crates.io API or database.
One other thing to keep in mind: we would not only have to check exact matches but also semver matches. I'm not sure if the crates.io reverse dependency check (which powers the "dependends" tab) covers this.
I think the crates.io reverse dependencies list is the right point to start.
Using the crates.io API I generated the list of releases, @newpavlov can you confirm that the list is fine?
Then I'll trigger the rebuilds.
@syphar
Unfortunately, the list captures only crypto-common
. Crates which define algorithm traits (e.g. digest
) use generic-array
re-exported from crypto-common
. Finally, implementation crates (e.g. sha2
) implement the traits and thus use generic-array
which was re-exported from digest
, which in turn uses re-exported version from crypto-common
.
Ideally, we need to re-generate docs for crates which expose GenericArray
in their public API and which were published in a certain date range. But it looks too complex for resolving this relatively minor issue.
If we are fine with resolving this issue only for RustCrypto crates, then one option is to re-generate docs only for crates which have a RustCrypto group owner (e.g. github:rustcrypto:hashes
). Here is a list of relevant groups: AEADs, block-ciphers, crypto-bigint, elliptic-curves, formats, hashes, JOSE, KDFs, KEMs, key-wraps, MACs, nacl-compat, PAKEs, password-hashes, RSA, signatures, sponges, SSH, stream-ciphers, traits, utils.
@syphar Unfortunately, the list captures only
crypto-common
. Crates which define algorithm traits (e.g.digest
) usegeneric-array
re-exported fromcrypto-common
. Finally, implementation crates (e.g.sha2
) implement the traits and thus usegeneric-array
which was re-exported fromdigest
, which in turn uses re-exported version fromcrypto-common
.
🤦 I didn't think about dependencies of dependencies.
I'm not sure if doing the crates.io query recursively would even finish. And with semver, would take quite some time to figure out correctly.
Ideally, we need to re-generate docs for crates which expose
GenericArray
in their public API and which were published in a certain date range. But it looks too complex for resolving this relatively minor issue.
Sadly that kind of query is not possible yet (-> #1467).
If we are fine with resolving this issue only for RustCrypto crates, then one option is to re-generate docs only for crates which have a RustCrypto group owner (e.g.
github:rustcrypto:hashes
). Here is a list of relevant groups: AEADs, block-ciphers, crypto-bigint, elliptic-curves, formats, hashes, JOSE, KDFs, KEMs, key-wraps, MACs, nacl-compat, PAKEs, password-hashes, RSA, signatures, sponges, SSH, stream-ciphers, traits, utils.
fine with me for now.
Can you confirm that list? I checked the releases for the crates for these owners, where the build-status is failed.
You don't need the "build-status is failed" check (but you need to filter pre versions). The problematic docs are generated properly, they just don't have links generated for GenericArray
. For example, see the Digest
link in the OP. In other words, the list should contain sha2 v0.10.8
, digest v0.10.7
, block-buffer v0.10.4
, and crypto-common v0.1.6
.
(but you need to filter pre versions)
which?
without the build status filter I'm getting 2676 releases, which we could rebuild, but I would prefer having a filter.
For example, with sha2
we need to rebuild v0.10.8
, and ignore v0.11.0-pre*
versions. I think we can rebuild only the highest non-pre version for each crate. It would mean that sha2 v0.10.7
will be still affected, but probability of users reading its docs is much lower.
coming back to open issues.
I can queue rebuilds for any list of (name, version).
To safe us some back and forth around the list I would propose you generate that list, for example based on the crates.io database dump, which has all crates & their dependencies.
Or should we just wait for crate authors to ping us?
Sorry for the late reply! Here is a manually compiled list. It's far from being complete, but should cover most visible crates.
I queued the rebuilds.
Versions that didn't exist:
progress here: https://docs.rs/releases/queue
queued rebuilds for all three
Thank you!
A big number of RustCrypto crates was affected by https://github.com/rust-lang/rust/issues/120983 The bug was fixed, but many crates are still affected since no new releases were uploaded since. For example, see docs for
sha2::Digest
. Since we are currently preparing the next release cycle, we do not plan to publish new patch versions for many affected crates.Would it be possible to re-generate docs for all dependents of generic-array v0.14? The number of affected crates is too big to create this list manually.