[pull] master from rust-lang:master #65
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
While #14897 reported packages with an unsupported index schema version, that only worked if the changes in the schema version did not cause errors in deserializing `IndexPackage` or in generating a `Summary`. This extends that change by recoverying on error with a more lax, incomplete parse of `IndexPackage` which should always generate a valid `Summary`. To help with a buggy Index, we also will report as many as we can. This does not provide a way to report to users or log on cache reads if the index entry is not at least `{"name": "<string>", "vers": "<semver>"}`. As a side effect, the index cache will include more "invalid" index entries. That should be ok as we will ignore the invalid entry in the cache when loading it. Ignoring of invalid entries dates back to #6880 when the index cache was introduced. Fixes #10623 Fixes #14894
…playDepth` refactor(tree): replace previous `depth: u32` opts with new type `DisplayDepth`
…ackage_id belongs to ws
### What does this PR try to resolve? While #14897 reported packages with an unsupported index schema version, that only worked if the changes in the schema version did not cause errors in deserializing `IndexPackage` or in generating a `Summary`. This extends that change by recoverying on error with a more lax, incomplete parse of `IndexPackage` which should always generate a valid `Summary`. To help with a buggy Index, we also will report as many as we can. This does not provide a way to report to users or log on cache reads if the index entry is not at least `{"name": "<string>", "vers": "<semver>"}`. Fixes #10623 Fixes #14894 ### How should we test and review this PR? My biggest paranoia is some bad interaction with the index cache including more "invalid" index entries. That should be ok as we will ignore the invalid entry in the cache when loading it. Ignoring of invalid entries dates back to #6880 when the index cache was introduced. ### Additional information
I found a bug in the manifest parser and figured this would help make it more obvious. Since I was already changing the order, I figure I'm make things a little more logical (user-facing first, implementtion details later)
This bug has been there since #14360
### What does this PR try to resolve? This bug has been there since #14360 Found this when looking to change the normalization code for cargo script. As a result, I also changed `cargo-util-schemas` in the hope that grouping the fields would make the intent clearer. Since I was already changing field order, I also re-ordered for my personal taste (user facing features first) ### How should we test and review this PR? ### Additional information
It checks rustup existence even when test is skipped for other reasons
### What does this PR try to resolve? It checks rustup existence even when test is skipped for other reasons. ### How should we test and review this PR? See <rust-lang/rust#134278 (comment)>. ### Additional information
Users should be using the standard library `home_dir` instead of this crate.
This changes the release trigger to only run when a tag matching the pattern `0.*` is created. The intent is to allow us to create tags for other crates that we may release out-of-band of the normal releases (and maybe consider creating tags for all crates to make them easier to find). For example, I would like to create `home-0.5.11` tags (and earlier versions that were missed due to this trigger). cc #14538
This is in preparation to publish a new release of the home crate (from the current master branch).
<!-- Thanks for submitting a pull request 🎉! Here are some tips for you: * If this is your first contribution, read "Cargo Contribution Guide" first: https://doc.crates.io/contrib/ * Run `cargo fmt --all` to format your code changes. * Small commits and pull requests are always preferable and easy to review. * If your idea is large and needs feedback from the community, read how: https://doc.crates.io/contrib/process/#working-on-large-features * Cargo takes care of compatibility. Read our design principles: https://doc.crates.io/contrib/design.html * When changing help text of cargo commands, follow the steps to generate docs: https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages * If your PR is not finished, set it as "draft" PR or add "WIP" in its title. * It's ok to use the CI resources to test your PR, but please don't abuse them. ### What does this PR try to resolve? Explain the motivation behind this change. A clear overview along with an in-depth explanation are helpful. You can use `Fixes #<issue number>` to associate this PR to an existing issue. ### How should we test and review this PR? Demonstrate how you test this change and guide reviewers through your PR. With a smooth review process, a pull request usually gets reviewed quicker. If you don't know how to write and run your tests, please read the guide: https://doc.crates.io/contrib/tests ### Additional information Other information you want to mention in this PR, such as prior arts, future extensions, an unresolved problem, or a TODO list. -->
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept a `use-ld` flag. `-C linker` (which is already present in the test) is enough. This fixes the following warning found in rust-lang/rust#119286: ``` ---- expected: tests\testsuite\freshness.rs:2822:27 ++++ actual: stderr 1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo) 2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍ 3 + | 4 + = [NOTE] `#[warn(linker_messages)]` on by default 5 + 6 + [WARNING] `foo` (lib) generated 1 warning 2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s ```
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept a `use-ld` flag. `-C linker=rust-lld` (which is already present in the test) is enough. This fixes the following warning found in rust-lang/rust#119286: ``` ---- expected: tests\testsuite\freshness.rs:2822:27 ++++ actual: stderr 1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo) 2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍ 3 + | 4 + = [NOTE] `#[warn(linker_messages)]` on by default 5 + 6 + [WARNING] `foo` (lib) generated 1 warning 2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s ``` <!-- Thanks for submitting a pull request 🎉! Here are some tips for you: * If this is your first contribution, read "Cargo Contribution Guide" first: https://doc.crates.io/contrib/ * Run `cargo fmt --all` to format your code changes. * Small commits and pull requests are always preferable and easy to review. * If your idea is large and needs feedback from the community, read how: https://doc.crates.io/contrib/process/#working-on-large-features * Cargo takes care of compatibility. Read our design principles: https://doc.crates.io/contrib/design.html * When changing help text of cargo commands, follow the steps to generate docs: https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages * If your PR is not finished, set it as "draft" PR or add "WIP" in its title. * It's ok to use the CI resources to test your PR, but please don't abuse them. ### What does this PR try to resolve? Explain the motivation behind this change. A clear overview along with an in-depth explanation are helpful. You can use `Fixes #<issue number>` to associate this PR to an existing issue. ### How should we test and review this PR? Demonstrate how you test this change and guide reviewers through your PR. With a smooth review process, a pull request usually gets reviewed quicker. If you don't know how to write and run your tests, please read the guide: https://doc.crates.io/contrib/tests ### Additional information Other information you want to mention in this PR, such as prior arts, future extensions, an unresolved problem, or a TODO list. -->
### What does this PR try to resolve? In PR #14980, the Ord impl for SourceId was changed, but the comment wasn’t updated. So it is now incorrect. This PR updates the comment to match the implementation. ### How should we test and review this PR? Read the Ord for SourceId code and make sure the updated comment describes what it does. ### Additional information None
The text of the message was changed in rust-lang/rust#133154
Nightly recently introduced the `linker-messages` lint which prints any messages from linkers. These tests were triggering that lint because they were passing missing directories to the linker. This fixes it by creating empty directories to pass to the linker. Note that this lint will be downgraded soon via rust-lang/rust#136098, but it seemed worthwhile to fix the underlying problem. This also fixes a problem where build_script_needed_for_host_and_target was not testing for the correct command-line flags. These got lost in #14132.
There were some changes in the latest nightly which is breaking some tests: * rust-lang/rust#133154 updated the wording of a message. I adjusted the test to be less sensitive to the exact wording. * rust-lang/rust#119286 added the `linker-messages` lint which shows the output from the linker. Some of our tests were passing dummy flags to the linker, which it was complaining about. This updates it so that it uses real directories. * This also fixes an incidental issue, where `build_script_needed_for_host_and_target` was not testing for the correct command-line flags. These got lost in #14132.
### What does this PR try to resolve? This came up in #13623 to avoid putting tokens into shell history. ### How should we test and review this PR? The exact approach to deprecation can vary - Include `<token>` in at least some docs for discovery (most likely the man page) - Don't warn yet etc I also suspect we could reorganize `cargo help login` but wanted to decouple that from this change. ### Additional information
This fixes some warnings that show up on Windows:
```
warning: unused variable: `path`
--> tests\testsuite\registry.rs:3146:24
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^ help: if this is intentional, prefix it with an underscore: `_path`
|
= note: `#[warn(unused_variables)]` on by default
warning: unused variable: `permissions`
--> tests\testsuite\registry.rs:3146:37
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_permissions`
```
This fixes the `standard_lib::shared_std_dependency_rebuild` test while running on Windows. On my system, `CARGO_MANIFEST_DIR` is a normal windows-style path (`D:\rust\cargo`) with backslashes. That is not valid TOML syntax. I don't know why this doesn't fail on CI (maybe CI sets a unix-style current dir?).
This PR closes #15101. I fixed a typo and touched up some sentences.
This PR closes #15102. I fixed broken links in the SUMMARY.md and guide/index.md of the Cargo book.
### What does this PR try to resolve? This PR conditionally mark the `test` cfg as a well known cfg depending on the target unit "test" field (ie `lib.test = false`, `[[bin]] test = false` and others). This is related to rust-lang/rust#117778 and https://users.rust-lang.org/t/cargo-what-is-the-purpose-of-lib-test-false/102361. When defining `lib.test = false` (and others), any use of `cfg(test)` will trigger the `unexpected_cfgs` lint. ```toml [lib] test = false # will now warn on cfg(test) ``` ### How should we test and review this PR? Best reviewed commit by commit. Second commit removes the `test` cfg from the `--check-cfg` args. ### Additional information T-compiler [MCP#785](rust-lang/compiler-team#785) and #14963 were of preparatory work. r? @epage
Due to rendering limits with GitHub's markdown renderer, we're moving the changelog to the cargo book where it can be statically served under our control.
This is so that we temporarily keep a copy of the CHANGELOG in the original location until the website is updated.
This moves cargo's changelog to the cargo book. We're bumping into rendering limits on GitHub's side, so we're moving the changelog to the cargo book where it can be statically served under our control. This PR is structured in such a way that the original CHANGELOG.md file is kept in place (and history is preserved in the new copy). The intent is to wait until this PR makes it to the nightly channel, and then open a new PR that will delete the original. That will look something like ehuss@5ce7947. This makes use of a new mdbook feature in order to exclude the changelog chapter from the search index. It completely swamps the search results, so I think it is best to just exclude it. We'll need to coordinate with the release team so that future release notes link directly to the cargo book instead of GitHub.
### What does this PR try to resolve? This includes `CARGO_COMPLETE=` and `CARGO_COMPLETE=0` to disable completions. I'm wanting access to this for my bash script that runs Cargo out of the `target/debug` without the outer cargo doing the completions ### How should we test and review this PR? ### Additional information
…rs (#15124) Authentication errors shouldn't unconditionally recommend running `cargo login`, because alternative registries configured to use custom credential providers won't use the token obtained by `cargo login`.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )