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.
cleanup: Remove error-format special-case in `cargo fix`
`cargo fix` had some special handling to deal with ensuring that the `--error-format=json` flag was passed to rustc. However, cargo was changed in https://github.com/rust-lang/cargo/pull/7450 to always pass that flag. This special handling is no longer necessary, so this PR removes it.
`cargo fix` had some special handling to deal with ensuring that the
`--error-format=json` flag was passed to rustc. However, cargo was
changed in https://github.com/rust-lang/cargo/pull/7450 to always pass
that flag. This special handling is no longer necessary, so this PR
removes it.
`cargo fix`: always inherit the jobserver
https://github.com/rust-lang/cargo/pull/12951 changed `cargo fix` to ensure that `rustc` has access to the jobserver. However, it only did that for the final "verification" step. It was not set for any of the previous calls to rustc (which is up to ~5 calls).
I'm not sure if this was done intentionally, I did not see any discussion of this in #12951.
This isn't too important in the grand scheme of things, because `rustc` is not doing codegen, so the parallel behavior is currently not used. However, this removes an extraneous `warning: failed to connect to jobserver from environment variable` warning that is printed in cargo's log every time it runs rustc. It also might be relevant in the future if rustc enables the parallel frontend.
`cargo add` - fix for adding features from repository with multiple packages.
Fixes#13121
As discussed in the issue, when using `cargo add` to add a package with features from a git repository from one of it's members, the command might fail due to improper target for querying for said features.
This PR adds a test for this edge-case where we expect it to fail with current code. It also adds a fix for this, and updates the test to expect success.
While populating available features, the current code does a `Fuzzy` search which might lead to searching for features in a wrong member package. If we change it to an `Exact` query, we get back the proper member to search within.
Add cargo:rustc-cdylib-link-arg into RESERVED_PREFIXES list
After https://github.com/rust-lang/cargo/pull/12201 was merged, the `cargo:rustc-cdylib-link-arg` in build script no longer works
```rs
println!("cargo:rustc-cdylib-link-arg=-Wl");
println!("cargo:rustc-cdylib-link-arg=-undefined");
println!("cargo:rustc-cdylib-link-arg=dynamic_lookup");
```
chore(doc): doc for custom subcommands look up.
### What does this PR try to resolve?
as the https://github.com/rust-lang/cargo/issues/13194 metions, the lookup rules for custom subcommands are only reflected in comments inside the code, and it is time to inform users of this behavior through documentation.
### How should we test and review this PR?
### Additional information
New remap rules for git/registry dependencies:
* Git dependencies: remove ~/.cargo/git/checkouts prefix.
* Registry dependencies: remove ~/.cargo/registry/src prefix.
This make the remap rules fixed to a finite number,
minimizing the burden for users to configure debuggers.
fix: clarify `--path` is the installation source not destination
### What does this PR try to resolve?
There is a misunderstanding of “default location” mentioned in `cargo install --help`.
I don't think one-line explanation helps much there, So remove that imprecise description.
This PR also add more "from" for places mentioning installation sources.
### How should we test and review this PR?
Read the new help text.
Rework `--check-cfg` generation comment
While working on something related to `--check-cfg`, I looked back at this comment and realized it could be improved, so here is my PR improving it.
