Fix self-publish script.
Removes the dry run, since it won't work (verification fails since dependencies aren't actually published).
Also adds a sleep in-between publishing to give the index a moment to update.
Ensure `unstable.build-std` works like `-Zbuild-std`
This fixes an issue where the deserializer for `-Zbuild-std` was a bit
fancier than the `unstable.build-std` directive.
cc #8393
Make `cargo metadata` output deterministic
Uses BTreeMap instead of HashMap for the `cargo metadata` command, ensuring the output is sorted.
The change did not cause a measurable performance impact for running `cargo metadata` on `cargo` itself.
Fixes#8477
Uses BTreeMap instead of HashMap for the `cargo metadata` command.
The change did not cause a measurable performance impact for
running `cargo metadata` on `cargo` itself.
Fixes#8477
Switch to github actions
This commit switches our CI from Azure Pipelines to GitHub Actions. The intention here is to follow the "idiomatic" provider of CI for rust-lang, and otherwise GitHub Actions is better integrated with GitHub's UI right now too.
I'll need to tweak bors to actually `@bors: r+` this to have it successfully get merged, but I think it'd be good to get some review first.
Allow configuring unstable flags via config file
# Summary
This fixes#8127 by mapping the `unstable` key in `.cargo/config` to Z flags.
It should have no impact on stable/beta cargo, and on nightlies it gives folks the ability to configure Z flags for an entire project or workspace. This is meant to make it easier to try things like the [new features resolver](https://github.com/rust-lang/cargo/issues/8088) behavior, mtime-on-use, build-std, or timing reports across a whole project.
I've also included a small (but entirely independent) ergonomics change -- treating dashes and underscores identically in Z flags. That's along for the ride in this PR as the last commit, and is included here because it makes for more idiomatic toml file keys (`print_im_a_teapot = yes` vs `print-im-a-teapot = yes`). Please let me know if y'all would prefer that be in a separate PR, or not happen at all.
# Test Plan
Apologies if I've missed anything -- this is my first cargo contrib and I've tried to hew to the contributing guide. If I've slipped up, please let me know how and I'll fix it.
NB. My linux machine doesn't have multilib set up, so I disabled cross tests.
* `cargo test` passes for each commit in the stack
* I formatted each commit in the stack with `rustfmt`
* New tests are included alongside the relevant change for each change
* I've validated each test by locally undoing the code change they support and confirming failure.
* The CLI wins, for both enable and disabling Z flags, as you'd expect.
Keys in `unstable` which do not correspond with a Z flag will trigger an error indicating the invalid flag came from a config file read:
```
Invalid [unstable] entry in Cargo config
Caused by:
unknown `-Z` flag specified: an-invalid-flag
```
If you'd like to see a test case which isn't represented here, I'm happy to add it. Just let me know.
# Documentation
I've included commits in this stack updating the only docs page that seemed relevant to me, skimming the book -- `unstable.md`.
These tests demonstrate the current failure mode around
overlapping env keys and inner structs. To some extent this
is a limitation of mapping on to environment variables with
an underscore as both the namespace separator and the
substitute for dashes in flag names in that the mapping is
not strictly one-to-one.
Add support for rustc's `-Z terminal-width`.
This PR continues the work started in #7315, adding support for rustc's `-Z terminal-width` flag, which is used to trim diagnostic output to fit within the current terminal and was added in rust-lang/rust#63402 (with JSON emitter support in rust-lang/rust#73763).
At the time of writing, rust-lang/rust#73763 isn't in nightly, so the test added in this PR will fail, but it should pass tomorrow (I've confirmed that it works with a local rustc build).
cc @estebank
Avoid colliding with older Cargo fingerprint changes
The fingerprint format Cargo stores changed recently in a way that
older Cargos cannot understand. Unfortunately though older Cargos are
colliding on some compilation units trying to read the new format and
they're bailing out. This commit fixes this issue by ensuring that the
location for fingerprint metadata is different in older Cargos and newer
Cargos.
Fingerprint metadata is always stored in a location with a hash in the
file name. This hash typically includes the hash of rustc's version
information itself, but for units which don't have a `Metadata` it's a
much simpler hash which is much more likely to collide with other
versions of Cargo. The fix in this commit is to extract the metadata
version that we're hashing to a constant, and then also hash it for
generating a filesystem location to house fingerprint data for a unit
that has no `Metadata`.
Closes#8472Closes#8298
The fingerprint format Cargo stores changed recently in a way that
older Cargos cannot understand. Unfortunately though older Cargos are
colliding on some compilation units trying to read the new format and
they're bailing out. This commit fixes this issue by ensuring that the
location for fingerprint metadata is different in older Cargos and newer
Cargos.
Fingerprint metadata is always stored in a location with a hash in the
file name. This hash typically includes the hash of rustc's version
information itself, but for units which don't have a `Metadata` it's a
much simpler hash which is much more likely to collide with other
versions of Cargo. The fix in this commit is to extract the metadata
version that we're hashing to a constant, and then also hash it for
generating a filesystem location to house fingerprint data for a unit
that has no `Metadata`.
Closes#8472
This patch changes how ConfigMapAccess iterates k/v pairs when
deserializing structs.
Previously we produced keys for exactly the set of fields needed
for a struct, and errored out in the deserializer if we can't find
anything for that field.
This patch makes us produces keys from the union of two sets:
1. All fields that are both needed for the struct and can be found
in the environment.
2. All fields in the config table.
This change allows serde's codegen to handle both missing and
unknown fields via the usual derive annotations (default or
deny_unknown_fields respectively)
Disable long_file_names test if not supported on Windows.
This test will fail on Windows if Cargo's target directory is over 80 characters long (as it is in rust's CI).
This commit modifies the parsing of `-Z terminal-width` so that it can
optionally take a value and only uses `accurate_err_width` when the user
does not provide a value - therefore making the emission of `-Z
terminal-width` opt-in.
Signed-off-by: David Wood <david@davidtw.co>
This commit adds support for rustc's `-Z terminal-width` flag, which is
used to trim diagnostic output to fit within the current terminal.
Co-authored-by: David Wood <david@davidtw.co>
Signed-off-by: David Wood <david@davidtw.co>
The current behavior, with the default-false workaround in place,
is not able to identify extra members of the `unstable` table, so
it can't error on unexpected members.
I'll add this test back in with a Deserializer refactor to clean up
the extra logic added to CliUnstable.
Tests are currently failing, looks like there's something in the
Deserializer impl that's forcing field-missing errors even when
the serde `default` annotation is applied.
Obviously this only works with nightlies and all
that, but if you're e.g. testing resolver v2, want
to always have Ztiming on in your workspace, or
something like that, this makes it easier to do.
Add support for deserializing enums in config files
Implements `deserialize_enum` functionality to allow config options which are Rust enums.
@ehuss The code currently has some `todo!`s because I'm not sure how the custom `Deserializer` is supposed to do error handling.
Fixes#8450
Write GNU tar files, supporting long names.
Fixes#8452
If I understand the previous bugs correctly, long trees packaged using Cargo with this patch will be misinterpreted by Cargo from before Jan 2016. (Without this patch, they can't be written at all.)
To me that seems like long enough ago that it's safe to land this now.
- [x] Add a test.
