fix(embedded): Don't create an intermediate manifest
### What does this PR try to resolve?
More immediately, this is to unblock rust-lang/rust#112601
More generally, this gets us away from hackily writing out an out-of-line manifest from an embedded manifest. To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
### How should we test and review this PR?
A Commit at a time
### Additional information
In production code, this does not conflict with #12255 (due to #12262) but in test code, it does.
To parse the manifest, we have to write it out so our regular manifest
loading code could handle it. This updates the manifest parsing code to
handle it.
This doesn't mean this will work everywhere in all cases though. For
example, ephemeral workspaces parses a manifest from the SourceId and
these won't have valid SourceIds.
As a consequence, `Cargo.lock` and `CARGO_TARGET_DIR` are changing from being next to
the temp manifest to being next to the script. This still isn't the
desired behavior but stepping stones.
This also exposes the fact that we didn't disable `autobins` like the
documentation says we should.
The hope is this will result in more resilient comment handling, being
more consistent with rustdoc.
I also hoped for less code but `syn` is doing less than I had expected,
requiring us to copy code over from other parts of rust. It seems every
proc macro has to do this but there is no guide to it, so they all do it
differently, only covering the cases they thought to test for.
Note that this still won't support `include_str!()`.
Previously, fetches and clones would routinely fail with a panic
that indicated that pack-negotiation can't take longer than 1 round
with our previous `Naive` approach.
With this version of `gitoxide` there is now faithful support for both
the `consecutive` and the `skipping` algorithm and multiple rounds of
negotiations, which should make all clones and fetches possible.
The implementation hinges on passing information about the kind of clone
and fetch to the `fetch()` method, which then configures the fetch accordingly.
Note that it doesn't differentiate between initial clones and fetches as
the shallow-ness of the repository is maintained nonetheless.
Update windows-sys
This updates the windows-sys dependency from 0.45 to 0.48. This shouldn't add or remove any duplicate dependencies (since there are other dependencies still using 0.45 and 0.42). The intent is to move it along the direction towards unifying in the future (though it seems like a moving target that will be difficult to ever hit).
This also bumps the home crate version. I think it should be OK to make the migration from winapi to windows-sys a patch version, though there seems to be some issues with the way windows-sys works that could introduce some build-time problems in some situations (such as those encountered in https://github.com/rust-lang/rust/pull/108665 and https://github.com/rust-lang/rust/pull/106610). However, I don't expect too much of an issue.
This is a short-term option until we can have a better solution for
globbing. This does not update `benches/` to support which has a README
in there preventing globbing; this seems low-churn enough not to find a
solution for it.
On the next sync-up with rust-lang/rust, we'll need to update 4e46301258/src/bootstrap/tool.rs (L588-L603)Fixes#11988
This is primarily for the release process of rust-lang/rust.
Note that in rustc-worksace-hack[1] it enable http2 via libnghttp2,
cargo probably needs to enable it to compile in rust-lang/rust.
[1]: 992d154f3a/src/tools/rustc-workspace-hack/Cargo.toml (L77)
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
Some dependencies in `resolver-tests` do not have any license
information. This prevent it from being a member when integrating in
rust-lang/rust. Will figure it out after.
Co-authored-by: Scott Schafer <schaferjscott@gmail.com>
Co-authored-by: Eric Huss <eric@huss.org>
The `git2` implementation can leverage that `git2` provides a consistent
view on the objects to be index, so it looks like 33% of the time is spent
receiving objects, and the rest of the time is used resolving them.
In `gitoxide`, there are two distinct phases and these are exposed by the way
we obtain progress for two separate phases. We have to do some math to renormalize
those to a single, continuous progress by mapping the values for 'amount of objects'
to the first half and second half of the progress bar respectively.
This has the advantage of having the first phase (receiving objects) end at 50%
and the second phase (resolving deltas) at 100%.
chore: Update base64
This removes one of cargo's duplicate dependencies as found by #11761.
`base64` is a bit of a controversial crate right now. It is going through large API changes, making it not as ergonomic for basic cases, which has ticked off a number of people. I kept it for now because its elsewhere in our dependency tree.
Byron already updated `prodash` to use the latest `parking_lot`
Remaining duplicates
- `hex` is blocked on `crypto-hash` which seems to no longer be maintained
- `hashbrown` is blocked on `indexmap` (updated in master) and `imara-diff`
- `humantime`, `env_logger`, `hermit-abi` are present from the optional `pretty_env_logger` dependency (why are we using optional deps? #6348)
- `windows-sys` is held back by `schannel`, `tempfile`, and `mio`
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
