There are some tests in the rustfmt test suite that are ignored by
default. I believe these tests are ignored because they have caused
issues with the the `rust-lang/rust` test suite.
However, we recently experienced an issue (5395) that would have been
avoided had these tests been running.
With the introduction of the new `#[rustfmt_only_ci_test]` attribute
macro we can run these tests when the `RUSTFMT_CI` environment variable
is set, which will presumably only be set during rustfmts CI runs.
When the environment variable is not set the `#[rustfmt_only_ci_test]`
will be replaced with an `#[ignore]`.
Fixes 5395
In PR 5239 we switched from using `structopt` to `clap`. It seems that
the default behavior for `clap` is to override the `--version` flag,
which prevented our custom version display code from running.
The fix as outlined in https://github.com/clap-rs/clap/issues/3405 was
to set `#[clap(global_setting(AppSettings::NoAutoVersion))]` to prevent
clap from setting its own default behavior for the `--version` flag.
* config_proc_macro: fix failing doctests
* ci: include config_proc_macro crate in ci
* [review] working native windows ci
* [fix] add --locked file for ci
* [fix] quoting of cmd variables
By setting this value in the Cargo.toml rust-analyzer understands that
rustfmt uses compiler-internals using `extern crate`.
This is a universal step that all developers will need to take in order to
get better type hints and code completion suggestions for
compiler-internals in their editor.
**Note**: users will also need to install the `rustc-dev` component via
`rustup` and add the following to their rust-analyzer configuration:
```json
{
"rust-analyzer.rustcSource": "discover",
"rust-analyzer.updates.channel": "nightly"
}
```
Support lint expectations for `--force-warn` lints (RFC 2383)
Rustc has a `--force-warn` flag, which overrides lint level attributes and forces the diagnostics to always be warn. This means, that for lint expectations, the diagnostic can't be suppressed as usual. This also means that the expectation would not be fulfilled, even if a lint had been triggered in the expected scope.
This PR now also tracks the expectation ID in the `ForceWarn` level. I've also made some minor adjustments, to possibly catch more bugs and make the whole implementation more robust.
This will probably conflict with https://github.com/rust-lang/rust/pull/97718. That PR should ideally be reviewed and merged first. The conflict itself will be trivial to fix.
---
r? `@wesleywiser`
cc: `@flip1995` since you've helped with the initial review and also discussed this topic with me. 🙃
Follow-up of: https://github.com/rust-lang/rust/pull/87835
Issue: https://github.com/rust-lang/rust/issues/85549
Yeah, and that's it.
When useing `version=One` rustfmt will treat the leading `r#` as part of
the `UseSegment` used for sorting. When using `version=Two` rustfmt will
ignore the leading `r#` and only consider the name of the identifier
when sorting the `UseSegment`.
There are some proposed import sorting changes for raw identifier `r#`.
These changes constitute a breaking change, and need to be version
gagted. Before version gating those changes we add the version
information to the `UseSegment`.
There was recently an issue where `cargo install` was installing a newer
version of a dependency than the one listed in our Cargo.toml. The newer
version added deprecation warnings that caused our continuous integration
tests to break.
As mentioned in the `cargo help install` docs, passing the `--locked`
flag should force cargo to use the `Cargo.lock` file included with
the repository.
Closes 3937
It's unclear which change fixed the `format_code_in_doc_comments=true`
issue brought up in this issue, however I'm unable to reproduce the
error on the current master.
The added test cases should serve to prevent a regression.
Remove hacks in `make_token_stream`.
`make_tokenstream` has three commented hacks, and a comment at the top
referring to #67062. These hacks have no observable effect, at least as judged
by running the test suite. The hacks were added in #82608, with an explanation
[here](https://github.com/rust-lang/rust/pull/82608#issuecomment-812877329). It
appears that one of the following is true: (a) they never did anything useful,
(b) they do something useful but we have no test coverage for them, or (c)
something has changed in the meantime that means they are no longer necessary.
This commit removes the hacks and the comments, in the hope that (b) is not
true.
r? `@Aaron1011`
