This attempts to centralize all the edition stuff in one place (the
`Edition` enum) so that adding a new edition or stabilizing one should
be relatively little work (and more importantly, we don't miss things).
Importantly, this changes `cargo new` to default to the latest stable.
It also changes the `cargo fix --edition-idiom` behavior to only apply
idioms for the *current* edition.
* `--edition` always means "next" edition.
* `--edition` when on the most recent edition is not an error, just a warning.
* Support fix to 2021 edition.
What was previously "Fixing" was a message for after the fixes had
been applied. I think it would be clearer if it said "Fixed",
to indicate that the fixes had actually finished.
The new "Fixing" is posted just before it starts. This is verbose-only
since it is a little noisy.
Generalized `clippy_is_available` and renamed as `command_is_available`.
No checks in `ignores_failure_to_format_source`, it's not supposed to
use `rustfmt` even if it's available
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
