We achieved this by:
* Handle `--output-format` argument, accepting `html` or `json`
* If `json` is passed, we append the following in
`prepare_rustdoc`:
1. `-Zunstable-options`
2. `--output-format`
Fixes#12103
Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
fix(manifest): Provide unused key warnings for lints table
### What does this PR try to resolve?
The use of `flatten` was getting in the way of `serde_ignored`.
A common workaround is to add our own `unused` tracking but that would
cause duplicates with `workspace.lints` (or we'd just ignore it).
Since the manual deserializer was relatively simple, I went that route.
Fixes#12917
### How should we test and review this PR?
Per commit
A test was added for the issue. I then was worried about regressions in `workspace = false` errors (and I was right) so I added a test for that. To get `workspace = false` to work nicely, I made it share code with other `workspace: bool` fields.
### Additional information
test(manifest): Verify we warn on unused workspace.package fields
I assumed from #13258 that we didn't warn but apparently we do. Figured it'd still be good to keep the test around.
docs(changelog): Call out cargo-new lockfile change
I was looking for what release this happened in but we didn't have it listed.
We do list the documentation change.
This was likely from the PR focusing on the entire policy change which made it easy to overlook each aspect of the policy change.
The use of `flatten` was getting in the way of `serde_ignored`.
A common workaround is to add our own `unused` tracking but that would
cause duplicates with `workspace.lints` (or we'd just ignore it).
Since the manual deserializer was relatively simple, I went that route.
Fixes#12917
I was looking for what release this happened in but we didn't have it
listed.
We do list the documentation change.
This was likely from the PR focusing on the entire policy change which
made it easy to overlook each aspect of the policy change.
chore: Add dependency dashboard
Example: https://github.com/clap-rs/clap/issues/4824
I'm hoping this will make it easier to see what is going on with problems with RenovateBot, like our MSRVs not updating atm (#13254).
feat(embedded): Add prefix-char frontmatter syntax support
This is a follow up to #13241 with another syntax being discussed. This one is a bit more polarizing but we're hoping first-hand experience with it can help people get a feel for how well it works in practice.
As the experiment is meant to be short-lived, this is implemented in a hacky way and docs aren't updated.
Update dependency handlebars to v5 for mdman.
### What does this PR try to resolve?
issue #13238
- update dependency handlebars 4.5.0 -> 5.0.0
- fix code to fit the changes of Handlebars API
- RenderError::new() is deprecated. Use RenderErrorReason instead
### How should we test and review this PR?
pass all tests in /crates/mdman/tests
This is a follow up to #13241 with another syntax being discussed.
This one is a bit more polarizing but we're hoping first-hand experience
with it can help people get a feel for how well it works in practice.
As the experiment is meant to be short-lived, this is implemented in a
hacky way and docs aren't updated.
feat(embedded): Add multiple experimental manifest syntaxes
### What does this PR try to resolve?
As syntax discussions for "cargo script" are on-going, this allows us to experiment with a couple of them so we can see how they work in practice.
This is missing the line-prefix syntax as we decide how we want to separate blocks for it.
While doing this, I removed the previous doc-comment syntax. This was left in for transition purposes. With where discussions are going, its unlikely we'll go back to that syntax.
### How should we test and review this PR?
### Additional information
rust-lang/rfcs#3503https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Syntax.20for.20embedded.20tooling.20metadata
test: support publish package with a `public` field.
### What does this PR try to resolve?
This PR add a `public` alike method to support add a dependency as public/private,
```
Package::new("foo", "0.1.0")
.cargo_feature("public-dependency").add_dep(Dependency::new("bar", "0.1.0").public(true))
```
and then get it from registry in test.
This PR was seperated from the https://github.com/rust-lang/cargo/pull/13183.
### How should we test and review this PR?
You can review on per commit.
After running the test case `publish_package_with_public_dependency`, you can check a "public" field in `./target/tmp/cit/t0/registry/3/b/bar`.
### Additional information
r? epage
`cargo fix`: Call rustc fewer times.
This is an improvement of `cargo fix` so that it calls `rustc` one fewer times per target. The original code an extra step of calling `rustc` to display final diagnostics to the user. Part of the reason is that in the past, cargo did not always use JSON, and so `cargo fix` was forced to call `rustc` with and without JSON. Now that cargo uses JSON all the time, that is not necessary. This avoids the final call to `rustc` by remembering the original output from `rustc`.
This needs to keep track of both the first and last output from `rustc`. This is to handle the situation where `cargo fix` fails to apply some suggestion (either because the verification fails, or `rustfix` fails). The `cargo fix` output includes both the error, and the original diagnostics before the error.
The first commit is a little test framework to exercise the various edge cases around how fix works. The comments should explain how it works, but it essentially has a `rustc` replacement that emits various different diagnostics and counts how often it is called.
The subsequent commit includes the change to keep track of the output from `rustc` and to avoid the final call.
Fixes#13215
This adds a set of tests which validates various edge cases around how
`cargo fix` works in terms of calling `rustc` multiple times. This uses
a replacement of `rustc` so it doesn't depend on the behavior of rustc
itself which is not always stable.
We added code fence support in ba869d36ed
(September), so I think this was enough of a transition period and there
is little interest in going back to this.
Contrib: Fix team HackMD links
This adjusts the links in the contrib guide to HackMD to use links which are publicly visible. I did not intend to use the other links which AFAIK are private to team members.
chore(deps): update alpine docker tag to v3.19
[![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| alpine | final | minor | `3.18` -> `3.19` |
---
### Configuration
📅 **Schedule**: Branch creation - "before 5am on the first day of the month" (UTC), Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box
---
This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/rust-lang/cargo).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4xMDMuMSIsInVwZGF0ZWRJblZlciI6IjM3LjEwMy4xIiwidGFyZ2V0QnJhbmNoIjoibWFzdGVyIn0=-->
rustfix: Support inserting new lines.
If rustfix received a suggestion which inserts new lines without replacing existing lines, it would ignore the suggestion. This is because `parse_snippet` would immediately return if the `lines` to replace was empty.
The solution here is to just drop the code which messes with the original text line. `cargo fix` (and compiletest) currently do not use this. This was originally added back in the days when rustfix supported an interactive UI which showed color highlighting of what it looks like with the replacement. My feeling is that when we add something like this back in, I would prefer to instead use a real diff library and display instead of trying to do various text manipulation for display. This particular code has generally been buggy, and has been a problem several times.
The included test fails without this fix because the changes do not apply, and the code cannot compile.
This also includes a little bit of cleanup for the `parse_and_replace` test. My feeling is that this test could use further improvements.
Fix fix::fix_in_dependency to not rely on rustc
This changes the `fix::fix_in_dependency` test so that it does not rely on the behavior of rustc.
This test is checking the behavior when rustc includes a suggestion diagnostic that modifies a file in CARGO_HOME from a dependency. rustc should not be emitting suggestions that point outside of the current crate, but there are some known bugs where it does this. #9938 added a workaround for this to avoid writing to CARGO_HOME.
However, the current test was relying on one of those bugs in rustc to exhibit its behavior. https://github.com/rust-lang/rust/pull/119204 is fixing that particular behavior. Instead of relying on issues in rustc, this PR changes the test so that the test creates a fake `rustc` executable that will emit a hard-coded JSON message that tells `cargo fix` to modify a file in CARGO_HOME. This should be stable as it is no longer relying on rustc.
Testing or validating this change is a little tricky. You have to essentially comment out [these three lines](4f70d1781a/src/cargo/ops/fix.rs (L654-L656)) from the original #9938 change, and verify that the test fails (it says "Fixed" in the output). With those three lines in place, it should pass.
Suggestions that come from rustc that are multi-line only use LF line
endings. But if the file is checked out on windows with CRLF
line-endings, then you end up with a mix of line endings that don't
match the "fixed.rs" file.
Tracking this at https://github.com/rust-lang/rust/issues/119482.
If rustfix received a suggestion which inserts new lines without
replacing existing lines, it would ignore the suggestion. This is
because `parse_snippet` would immediately return if the `lines` to
replace was empty.
The solution here is to just drop the code which messes with the
original text line. `cargo fix` (and compiletest) currently do not use
this. This was originally added back in the days when rustfix supported
an interactive UI which showed color highlighting of what it looks like
with the replacement. My feeling is that when we add something like this
back in, I would prefer to instead use a real diff library and display
instead of trying to do various text manipulation for display. This
particular code has generally been buggy, and has been a problem several
times.
The included test fails without this fix because the changes do not
apply, and the code cannot compile.