Cargo has of #7143 enabled pipelined compilation by default which
affects how the compiler is invoked, especially with respect to JSON
messages. This, in some testing, has proven to cause quite a few issues
with rustbuild's current integration with Cargo. This commit is aimed at
adding features to Cargo to solve this issue.
This commit adds the ability to customize the stream of JSON messages
coming from Cargo. The new feature for Cargo is that it now also mirrors
rustc in how you can configure the JSON stream. Multiple
`--message-format` arguments are now supported and the value specified
is a comma-separated list of directives. In addition to the existing
`human`, `short`, and `json` directives these new directives have been
added:
* `json-render-diagnostics` - instructs Cargo to render rustc
diagnostics and only print out JSON messages for artifacts and Cargo
things.
* `json-diagnostic-short` - indicates that the `rendered` field of rustc
diagnostics should use the "short" rendering.
* `json-diagnostic-rendered-ansi` - indicates that the `rendered` field of rustc
diagnostics should embed ansi color codes.
The first option here, `json-render-diagnostics`, will be used by
rustbuild unconditionally. Additionally `json-diagnostic-short` will be
conditionally used based on the input to rustbuild itself.
This should be enough for external tools to customize how Cargo is
invoked and how all kinds of JSON diagnostics get printed, and it's
thought that we can relatively easily tweak this as necessary to extend
it and such.
Switch from unused_imports to deprecated to test unfixable warnings
The `unused_imports` warning is going to emit fixable suggestions in the near future, but that means parts of the cargo's test suite will break. This commit switches the tests to use the `deprecated` warning, which *shouldn't* be fixable at all.
The unused_imports warning is going to emit fixable suggestions in the
near future, but that means parts of the cargo's test suite will break.
This commit switches the tests to use the deprecated warning, which
*shouldn't* be fixable at all.
I originally opted to report bugs to Cargo instead of Rust because I was
afraid of the implementation of `cargo fix` itself. These seem to all be
weeded out now (largely at least), and the overwhelming majority of bugs
are now rust-lang/rust suggestion bugs. Let's suggest reporting bugs
directly there!
Display errors when `cargo fix` fails.
It can be difficult to figure out what's wrong when a user reports that `cargo fix` fails. It can be hard to figure out which suggestion caused a compile error, especially if the error is in another file/location.
If `cargo fix` attempts to fix multiple targets concurrently that have shared
source files, it would apply fixes multiple times causing corruption of the
source code. Fix this by locking on the package path instead of the target
filename, essentially serializing all targets within a package.
It can be difficult to figure out what's wrong when a user reports that
`cargo fix` fails. There's often a large list of warnings, and it can
be hard to figure out which one caused a compile error.
This commit updates the behavior of `cargo fix` when the `--broken-code`
flag is passed to Cargo. Previously Cargo would always back out
automatically applied changes to files whenever the fixed code failed to
compile. Now, with the `--broken-code` flag, fixed code is left as-is.
This means that if the fixed code can be more easily inspected by
humans to detect bugs and such.
The main use case intended here is that if you're working with a large
code base then lints like the edition idiom lints aren't 100% finished
yet to work as smoothly as `cargo fix`. The idiom lints are often
useful, however, to transition code to be idiomatic (who would have
guessed!) in the new edition.
To ease the experience of using not-quite-ready lints this flag can be
used to hopefully "fix 90% of lint warnings" and then the remaining
compiler errors can be sifted through manually. The intention is that we
have edition documentation indicating this workflow which also
encourages filing bugs for anything that fails to fix, and hopefully
this new behavior will make it easier for us to narrow down what the
minimal test case is too!
Currently Cargo runs the risk of turning on the edition lints for crates
which `cargo fix` isn't actually fixing, which means you'll get a huge
deluge of lints that would otherwise be automatically fixable! Fix this
situation by only enabling lints in the same cases that we're actually
applying fixes.
Closesrust-lang-nursery/rustfix#150
Replace 'project' with 'package' in many strings and comments.
Partial fix for #6056.
Shouldn't be anything too interesting or surprising in here.
Still need to do documentation, but will do that as a different PR.
Stabilize `edition` key and add `cargo new --edition`
This commit stabilizes the `edition` key in `Cargo.toml`, both in the
`[package]` section and inside subtargets. Additionally the `cargo new` and
`cargo init` subcommands have been enhanced with a `--edition` flag to allow
explicitly specifying the edition to be generated.
This commit does not yet change the default edition that's generated.
Closes#5980
This commit stabilizes the `edition` key in `Cargo.toml`, both in the
`[package]` section and inside subtargets. Additionally the `cargo new` and
`cargo init` subcommands have been enhanced with a `--edition` flag to allow
explicitly specifying the edition to be generated.
This commit does not yet change the default edition that's generated.
Closes#5980
This commit fixes the interaction of `cargo fix` and `RUSTC_WRAPPER`, ensuring
that Cargo at least doesn't die internally. For now `RUSTC_WRAPPER` is
overridden for normal execution but we can eventually one day probably support
`RUSTC_WRAPPER`!
Closes#5981
Force `cargo fix` to rebuild
Fixes#5736
This is a resubmit of @killercup's #5750, rebased on current master.
@alexcrichton From browsing the code I feel like `-p` would still restrict the packages to rebuild, despite the rebuild flag added. But I might be misreading or not-fully-reading the code. Could you give me some mentoring instructions for the test cases you're concerned with?
* master: (25 commits)
Migrate from tests fom assert_that/execs to .run()
Wrap ProcessBuilder in Execs & make .cargo return that
Make old Execs methods take not consume self
Extract Execs::match_process
Add #[must_use] to Execs
Inline Execs::_with_stderr
Remove an unrun "cargo build" ProcessBuilder
Add documentation for creating test dependencies.
Only use non-absolute paths for `path` dependencies
Fix test failure on nightly due to `codemap::Span` change.
New metabuild strategy using custom src_path enum.
Remove unnecessary change.
Address review comments.
Metabuild (RFC 2196)
Handle Window's missing file error message
Make "cargo uninstall" uninstall the cwd bins
update comment based on further research
List URL in HTTP download failures
Fix compilation error
Improve the `cargo install` deprecation messaging
...
This change splits out staged changes from dirty changes, and lets the
user know if they should consider using the --allow-staged flag.
Signed-off-by: Jordan Justen <jljusten@gmail.com>
