Remove dependency on `winapi` 0.2
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
cargo
\- crates-io
\- http
\- bytes
\- iovec
\- winapi 0.2
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
This commit removes Cargo's dependency on `winapi` 0.2 which takes an
excessively long time to build, slowing down Windows builds. The
`winapi` 0.2 crate was pulled in via a dependency chain that looked
like:
cargo
\- crates-io
\- http
\- bytes
\- iovec
\- winapi 0.2
The fix implemented here was to remove the `http` crate dependency from
`crates-io` which is only used for rendering status codes, but it's easy
enough to inline that function locally.
Fix some duplicate artifact problems.
The recent cargo update failed because of duplicate artifacts with rls.
`tar` should mirror what the main manifest contains.
Partially revert #7374 by adding `serde` back to `url`. Unfortunately the `lsp-types` crate (used by rls) needs this feature. Unless anyone has a good idea on how to handle that, I don't think it can be removed.
Unblocks cargo update, which I'd like to get done before the beta branch.
Added ability to crosscompile doctests
This commit adds the ability to cross-compile and run doctests.
Like before cargo checks if target == host, the difference is that if there is a runtool defined in config.toml, it passes the information forward to rustdoc so that it can run the doctests with that tool. If no tool is defined and the target != host, cargo instead displays a message that doctests will not be compiled because of the missing runtool.
See [here](https://github.com/rust-lang/rust/pull/60387) for the companion PR in the rust project that modifies rustdoc to accept the relevant options as well as allow ignoring doctests on a per target level.
Partially resolves [#6460](https://github.com/rust-lang/cargo/issues/6460)
See [here](https://github.com/rust-lang/cargo/issues/7040) for the tracking issue.
Update hex requirement from 0.3 to 0.4
Updates the requirements on [hex](https://github.com/KokaKiwi/rust-hex) to permit the latest version.
<details>
<summary>Commits</summary>
- See full diff in [compare view](https://github.com/KokaKiwi/rust-hex/commits)
</details>
<br />
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme
Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Pull request limits (per update run and/or open at any time)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)
Finally, you can contact us by mentioning @dependabot.
</details>
Don't require the `serde` feature of `url`
Ends up meaning that in full crate compiles that `url` doesn't wait for
`serde` to finish, which in turn enables crates like `git2` to start
sooner!
Experiment: Create timing report.
This is just an experiment, so I'm not sure if we'll want to merge it.
This adds an HTML report which gets saved to disk when the build is finished. It is primarily geared for identifying slow dependencies, and for visualizing how pipelining affects the build.
Here's an example: https://ehuss.github.io/cargo-timing.html
You can mouse over the blocks to highlight the reverse-dependencies that are released when a unit finishes. `syn` is a really good example.
It does a few other things, like displaying a message after each unit is finished. See the docs for more information.
Work with canonical URLs in `[patch]`
This commit addresses an issue with how the resolver processes `[patch]`
annotations in manifests and lock files. Previously the resolver would
use the raw `Url` coming out of a manifest, but the rest of resolution,
when comparing `SourceId`, uses a canonical form of a `Url` rather than
the actual raw `Url`. This ended up causing discrepancies like those
found in #7282.
To fix the issue all `patch` intermediate storage in the resolver uses a
newly-added `CanonicalUrl` type instead of a `Url`. This
`CanonicalUrl` is then also used throughout the codebase, and all
lookups in the resolver as switched to using `CanonicalUrl` instead of
`Url`, which...
Closes#7282
This commit addresses an issue with how the resolver processes `[patch]`
annotations in manifests and lock files. Previously the resolver would
use the raw `Url` coming out of a manifest, but the rest of resolution,
when comparing `SourceId`, uses a canonical form of a `Url` rather than
the actual raw `Url`. This ended up causing discrepancies like those
found in #7282.
To fix the issue all `patch` intermediate storage in the resolver uses a
newly-added `CanonicalUrl` type instead of a `Url`. This
`CanonicalUrl` is then also used throughout the codebase, and all
lookups in the resolver as switched to using `CanonicalUrl` instead of
`Url`, which...
Closes#7282
Clear out memoized hashes before building crates
Build script updates during execution can change the memoized hash of a
`Fingerprint`, and while previously we cleared out a single build
script's memoized hash we forgot to clear out everything that depended
on it as well. This commit pessimistically clears out all `Fingerprint`
memoized hashes just before building to ensure that during the build
everything has the most up-to-date view of the world, and when build
scripts change fingerprints everything that depends on them won't have
run yet.
Closes#7362
Build script updates during execution can change the memoized hash of a
`Fingerprint`, and while previously we cleared out a single build
script's memoized hash we forgot to clear out everything that depended
on it as well. This commit pessimistically clears out all `Fingerprint`
memoized hashes just before building to ensure that during the build
everything has the most up-to-date view of the world, and when build
scripts change fingerprints everything that depends on them won't have
run yet.
Closes#7362
Improve test suite for `-Zbuild-std`
This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in
general making the `-Zbuild-std` tests more robust. The main change here
is that a new source tree is checked in, `tests/testsuite/mock-std`,
which mirrors rust-lang/rust's own tree for libstd. This mock tree is as
empty as it can be, ideally duplicating almost nothing but for not
requiring duplication of Cargo metadata about patches and such.
The end result here looks like:
* All `-Zbuild-std` tests are now run in parallel
* All tests run much more quickly since they're compiling tiny crates
instead of actually compiling libstd/libcore
* No tests require network access
* We verify that crates have access to the "custom" libraries
that we build
Coverage of tests is not currently expanded, but it's hoped that we
could add that shortly afterwards. Coverage has actually gone down
slightly since the custom target test was commented out temporarily and
the full integration test of running `-Zbuild-std` isn't run on CI any
more.
Closesrust-lang/wg-cargo-std-aware#33
Only run these tests on one CI builder (not all platforms) though. This
is extremely resource intensive since it rebuilds libstd. Currently this
does not share a build directly like before because the number of tests
are supposed to be small, but if necessary we can add that in later too.
This commit is aimed directly at rust-lang/wg-cargo-std-aware#33 and in
general making the `-Zbuild-std` tests more robust. The main change here
is that a new source tree is checked in, `tests/testsuite/mock-std`,
which mirrors rust-lang/rust's own tree for libstd. This mock tree is as
empty as it can be, ideally duplicating almost nothing but for not
requiring duplication of Cargo metadata about patches and such.
The end result here looks like:
* All `-Zbuild-std` tests are now run in parallel
* All tests run much more quickly since they're compiling tiny crates
instead of actually compiling libstd/libcore
* No tests require network access
* We verify that crates have access to the "custom" libraries
that we build
Coverage of tests is not currently expanded, but it's hoped that we
could add that shortly afterwards. Coverage has actually gone down
slightly since the custom target test was commented out temporarily and
the full integration test of running `-Zbuild-std` isn't run on CI any
more.
Closesrust-lang/wg-cargo-std-aware#33
Don't hang when Cargo's worker threads panic
This shouldn't ever happen during normal development, but happens from
time to time while developing Cargo itself.
Closes#6433
Pass --crate-type to rustdoc
This supports the [corresponding rustc PR](https://github.com/rust-lang/rust/pull/62855). To enable rustdoc to properly
document macros, we pass a new flag '--proc-macro-crate' when
documenting a proc-macro crate. This causes rustdoc to enable the
proc-macro compiler logic that runs when rustc is building a proc-macro
crate.
This flag is essentially a more restricted version of
'--crate-type=proc-macro'. I didn't think it was necessary to pass the
full '--crate-type' flag to rustdoc, when only two options would ever be
used (proc-macro vs anything else).
[-Zbuild-std] Only build libtest when libstd is built
Currently `libtest` is always compiled when a compilation unit uses a test harness. This implicitly adds builds the standard library too because `libtest` depends on it. This breaks the use of custom test frameworks in `no_std` crates as reported in https://github.com/rust-lang/cargo/pull/7216#issuecomment-529433594.
This pull request fixes the issue by only building `libtest` if `libstd` is built. This makes sense in my opinion because when the user explicitly specified `-Zbuild-std=core`, they probably don't want to build the full standard library and rather get a compilation error when they accidentally use `libtest`.
Parse `unsupported crate type` error more tightly
Fixes#7363
Instead of adding a new test, we could also rename the target file in an existing custom target test if you prefer.
