As of serde 1.0.172, `serde_derive` ships a binary blog for Linux x64
for faster build times. This blob is not yet reproducible to ensure
that the safety of it. See serde-rs/serde#2538
This is not a judgement on serde or on dtolnay but just a precaution to
buy us more time as the community works through this since the beta cut
is coming up. rust-1.72 branch is unaffected.
cargo-credential-gnome-secret: dynamically load libsecret
Building `cargo-credential-gnome-secret` currently requires the `libsecret` development libraries to be installed and findable via `pkg-config`. This is often an extra step for users and complicates CI builds.
This loads the required functions from `libsecret` dynamically using `libloading` which uses `dlopen` internally.
Closes#12503
Testing this requires manually installing the credential provider on a system with libsecret set up. I tested it on Arch Linux.
Update pretty_env_logger to 0.5
This updates pretty_env_logger from 0.4.0 to 0.5.0. The primary motivation is to drop some dependencies like `atty`.
https://github.com/seanmonstar/pretty-env-logger/compare/v0.4.0...v0.5.0
I think the main change is updating to env_logger 0.7 to 0.10 which syncs with what is normally used by cargo.
fix(package): Recognize and normalize `cargo.toml`
### What does this PR try to resolve?
This solution is a blend of conservative and easy
- Normalizes `cargo.toml` to `Cargo.toml` on publish
- Ensuring we publish the `prepare_for_publish` version and include `Cargo.toml.orig`
- Avoids dealing with trying to push existing users to `Cargo.toml`
- All other cases of `Cargo.toml` are warnings
- We could either normalize or turn this into an error in the future
- When helping users with case previously, we've only handle the `cargo.toml` case
- We already should have a fallback in case a manifest isn't detected
- I didn't want to put in too much effort to make the code more complicated to handle this
As a side effect, if a Linux user has `cargo.toml` and `Cargo.toml`, we'll only put one of them in the `.crate` file. We can extend this out to also include a warning for portability for case insensitive filesystems but I left that for after rust-lang/cargo#12235.
### How should we test and review this PR?
A PR at a time will show how the behavior changed as the source was edited
This does add a direct dependency on `unicase` to help keep case-insensitive comparisons easy / clear and to avoid riskier areas for bugs like writing an appropriate `Hash` implementation. `unicase` is an existing transitive dependency of cargo.
### Additional information
Fixes#12384
[Discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60cargo.2Etoml.60.20on.20case.20insensitive.20filesystems)
To keep things simple, especially in getting a `Hash` implementation
correct, I'm leveraging `unicase` for case-insensitive
comparisons which is an existing dependency and I've been using for
years on other projects.
This also opens the door for us to add cross-platform compatibility
hazard warnings about multiple paths that would write to the same
location on a case insensitive file system. I held off on that because
I assume we would want #12235 first.
This does mean we can't test the "no manifest" case anymore because the
one case (no pun intended) I knew of for hitting it is now gone.
No code changes are required for the current uses of indexmap.
I also updated `toml_edit` to get its update to `indexmap 2`, and
`gix-hashtable` to align them all on `hashbrown 0.14`.
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.
