Document private items for binary crates by default
I suggested this change in default behavior [a long time ago](https://github.com/rust-lang/cargo/issues/1520#issuecomment-135215284) and [a year ago again](https://github.com/rust-lang/cargo/issues/1520#issuecomment-420616261). Both time, everyone seemed to agree that this is a good idea, so I thought I could just implement it.
This PR already changed the default behavior, but there are a few things we should talk about/I should do before merging:
- [x] ~~Do we *really* want this changed default behavior? If not, *why* not?~~ -> [yip](https://github.com/rust-lang/cargo/pull/7593#issuecomment-556482199)
- [x] Is changing this default behavior OK regarding backwards compatibility? -> [apparently](https://github.com/rust-lang/cargo/pull/7593#issuecomment-556482199)
- [x] ~~We should also probably add a `--document-only-public-items` flag or something like that if we change the default behavior. Otherwise users have no way to not document private items for binary crates. Right?~~ -> [We can do it later](https://github.com/rust-lang/cargo/pull/7593#issuecomment-557152039)
- [x] I should probably add some tests for this new behavior -> I did
- [ ] I don't like that I added `rustdoc_document_private_items` to `CompileOptions`, but this was the sanest way I could think of without rewriting a whole lot. Is this OK or how else would one do it? The flag would belong to `DocOptions`. But `compile` does not have access to that. Any ideas? Btw: If we also add `--document-only-private-items`, I would change the type from `bool` to `Option<bool>`.
Stabilize install-upgrade.
Tracking issue: #6797
This stabilizes the install-upgrade feature, which causes `cargo install` to reinstall a package if it appears to be out of date, or exit cleanly if it is up-to-date.
There are no changes from `-Zinstall-upgrade`. See [the old unstable docs](6a7f505a18/src/doc/src/reference/unstable.md (install-upgrade)) for a refresher on the details of what it does.
This also stabilizes the following changes:
- `--version` no longer allows an implicit version requirement like `1.2`. It must be either contain all 3 components (like `1.2.3`) or use a requirement operator (like `^1.2`). This has been a warning for a very long time, and is now changed to a hard error.
- Added `--no-track` to disable install tracking.
**Motivation**
I just personally prefer this behavior, and it has been requested a few times in the past. I've been using it locally, and haven't run into any issues. If this goes into 1.41, then it will release on Jan 30, about 10 months since it was added in #6798.
**Concerns**
Regarding some of the concerns I had:
- Is it tracking the correct set of information?
I'm satisfied with the current set. It also tracks, but does not use, the version of rustc and the version specified in the `--version` flag, in case we ever want to use that in the future. It is also designed to be backwards and forwards compatible, so more information can be added in the future. I think the current set strikes a good balance of tracking the really important things, without causing unnecessary rebuilds.
- Method to upgrade all outdated packages?
This can always be added as a new flag or command in the future, and shouldn't block stabilization.
- Should `--no-track` be kept? Does it work correctly?
I kept it. It's not too hard to support, and nobody said anything (other than maybe using a less confusing name).
- Should this be the default? Should there be a way to use the old behavior?
I like it as the default, and don't see a real need for the old behavior. I think we could always bring back the old behavior with a flag in the future, but I would like to avoid it for simplicity. There is also the workaround of `which foo || cargo install foo`.
Closes#6797.
Closes#6727.
Closes#6485.
Closes#2082.
Turn the new lock file format on by default
This commit enables the support added in #7070 by default. This means
that gradually over time all `Cargo.lock` files will be migrated to the
new format. Cargo shipped with Rust 1.38.0 supports this new lock file
format, so any project using Rust 1.38.0 or above will converge quickly
onto the new lock file format and continue working.
The main benefit of the new format is to be more friendly to git merge
conflicts. Information is deduplicated throughout the lock file to avoid
verbose `depedencies` lists and the `checksum` data is all listed inline
with `[[package]]`. This has been deployed with rust-lang/rust for some
time now and it subjectively at least seems to have greatly reduced the
amount of bouncing that happens for touching `Cargo.lock`.
Ignore file lock errors if unsupported, on Windows
Not all file systems support file locking; WSL’s network file system doesn’t seem to, and I don’t think other network file systems will, either (though I haven’t checked them). ERROR_INVALID_FUNCTION is Windows’ equivalent to Unix’s ENOTSUP and Linux’s ENOSYS which are checked just above.
Fixes#7511.
Add hack for fwdansi change.
This is a hack to fix a test failing on CI.
The issue is that fwdansi 1.1 was published with a change on how it processes reset codes. I have filed https://github.com/kennytm/fwdansi/issues/2 with some details on some of the issues.
This is just a workaround to get the test to pass. I'm not too happy with it, but other choices seemed less than ideal. Am happy to consider them, though:
- Remove fwdansi, and give up supporting color on Win 7/8, old 10.
- Change `Shell` so that it knows whether or not the console supports ANSI, and only use fwdansi when necessary. This means Win 10 would stop using fwdansi, but 7/8 would continue to use it. It is a little awkward – I think it would have to call wincolor::set_virtual_terminal_processing and see if it succeeds.
- Wait for a change to fwdansi to make resets more transparent.
I am very tempted by the first choice. rustc's color output has been broken on win 7/8 for a long time, and only a very small number of people have complained. I have spent way too much time dealing with something I think nobody really uses.
cc @kennytm
Not all file systems support file locking; WSL’s network file system
doesn’t seem to, and I don’t think other network file systems will,
either (though I haven’t checked them). ERROR_INVALID_FUNCTION is
Windows’ equivalent to Unix’s ENOTSUP and Linux’s ENOSYS which are
checked just above.
Fixes#7511.
Remove "cargo login" from user input when asking for login token.
Hey all!
This is my first time contributing to open source, but I realized that I could help some people out and make a quick change. 😄
When running cargo login, I was told to `please visit https://crates.io/me and paste the API Token below`. However, me on autopilot accidentally pasted the whole `cargo login $APITOKEN` string on the website into `cargo login` and it took me almost 30 minutes to figure out why I couldn't publish a package.
I thought it would be useful to automatically remove `cargo login` from the token, just in case someone makes the brain dead mistake like me.
Hope I can get some good feedback on this, have a great one! ❤️
Fix all Clippy suggestions (but not add it to CI 🙃)
This PR adds a `clippy` job to the Azure Pipelines CI.
In addition to adding the job, I made sure to fix all the lints in all the packages.
I'm new to Rust, so please check my code modifications extra carefully 😂
Add kind/platform info to `cargo metadata`
This adds an array `"dep_kinds"` to the resolve nodes of the `cargo metadata` output. It looks something like this:
```javascript
"resolve": {
"nodes": [
"id": "cargo 0.39.0 (path+file:///Users/eric/Proj/rust/cargo2)",
"deps": [
{
"name": "bufstream",
"pkg": "bufstream 0.1.4 (registry+https://github.com/rust-lang/crates.io-index)",
"dep_kinds": [
{
"kind": "dev",
"target": null
}
]
},
{
"name": "winapi",
"pkg": "winapi 0.3.6 (registry+https://github.com/rust-lang/crates.io-index)",
"dep_kinds": [
{
"kind": null,
"target": "cfg(windows)"
}
]
}
]
]
}
```
This allows one to filter the graph based on the dependency kind and platform.
I'm not completely confident that this is the right course, but I can't think of a better design. In particular, it seems a little strange to include all platforms, but features get filtered. This is probably not a problem in practice (one can use `--all-features` to ensure all features are shown for the top-level packages). Filtering out based on platform is very difficult, because you cannot determine from the resolve alone which nodes will be host vs target. That requires the entire Unit graph. We may expose the Unit graph in the future, but this seems like a useful and simple step.
This is a draft because I wanted to discuss this before moving forward. I'd like to add some more tests.
cc #4632. This doesn't filter based on target, but does expose the target names. As mentioned above, I don't think filtering is possible.
cc #5583. This adds more information.
Closes#3984.
Closes#4631 (I think).
cc @sfackler who filed some of these issues.
Update core-foundation requirement from 0.6.0 to 0.7.0
Updates the requirements on [core-foundation](https://github.com/servo/core-foundation-rs) to permit the latest version.
<details>
<summary>Commits</summary>
- [`0a3ac83`](0a3ac83c1b) Auto merge of [#349](https://github-redirect.dependabot.com/servo/core-foundation-rs/issues/349) - wez:timertypes, r=jdm
- [`a119788`](a11978895e) even more version bumps
- [`6574b12`](6574b12d4a) more version bumps!
- [`0718126`](071812648a) Auto merge of [#350](https://github-redirect.dependabot.com/servo/core-foundation-rs/issues/350) - lqf96:fix-deprecated-usage, r=jdm
- [`83b6f5d`](83b6f5d20a) Use zero-initialized array in CFURL::to_path
- [`3126f15`](3126f15fd6) adjust test
- [`d3a097f`](d3a097f2a4) Use dyn for dynamic dispatch
- [`e438fc5`](e438fc54b9) Use ? instead of try macro
- [`727837f`](727837f12e) Use MaybeUninit instead of mem::uninitialized
- [`e7f687e`](e7f687e3d4) moar version bumps
- Additional commits viewable in [compare view](https://github.com/servo/core-foundation-rs/compare/core-foundation-v0.6.2...core-foundation-v0.7.0)
</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)
</details>
This commit adds support to Cargo and refactors the lockfile versioning
slightly. The goal here is that Cargo continually has two thresholds of
lockfile formats to create:
* One is used for new lock files at all times
* The other is used to update old lock files
The logic for these two thresholds is appropriately updated throughout
Cargo, and then this commit also preserves the previous update where new
lock files will get the new format, but old lockfiles will continue to
retain the old format by default.
This commit enables the support added in #7070 by default. This means
that gradually over time all `Cargo.lock` files will be migrated to the
new format. Cargo shipped with Rust 1.38.0 supports this new lock file
format, so any project using Rust 1.38.0 or above will converge quickly
onto the new lock file format and continue working.
The main benefit of the new format is to be more friendly to git merge
conflicts. Information is deduplicated throughout the lock file to avoid
verbose `depedencies` lists and the `checksum` data is all listed inline
with `[[package]]`. This has been deployed with rust-lang/rust for some
time now and it subjectively at least seems to have greatly reduced the
amount of bouncing that happens for touching `Cargo.lock`.
Fix unused configuration key warning for a few keys under `build`.
Recently cargo started to warn about configuration keys that he doesn't know about. However, there are a few keys under `build` that were used in a dynamic way (`rustc`, `rustdoc`, and `rustc_wrapper`) by `Config::maybe_get_tool()`.
Since these keys are not known to exist when `Config` is deserialized, cargo was emitting unused warnings.
This commit makes those config keys explicit. Note that by doing so there is a small breaking change: before it was possible to have `build.rustc_wrapper` in the configuration file (even though the documented key uses kebak-case), and now that key will be ignored. (Good thing we have warnings for unrecognized keys!)
Only include "already existing ..." comment in gitignore on conflict
I found the comment a bit confusing when I've used `cargo init` when I haven't had any conflicts. I thought it was meaning that my existing entries would be all commented out so I thought there was a bug of some kind.
This PR changes the comment to only be included when there are conflicting entries in the existing file.
