A `TokenStream` contains a `Lrc<Vec<(TokenTree, Spacing)>>`. But this is
not quite right. `Spacing` makes sense for `TokenTree::Token`, but does
not make sense for `TokenTree::Delimited`, because a
`TokenTree::Delimited` cannot be joined with another `TokenTree`.
This commit fixes this problem, by adding `Spacing` to `TokenTree::Token`,
changing `TokenStream` to contain a `Lrc<Vec<TokenTree>>`, and removing the
`TreeAndSpacing` typedef.
The commit removes these two impls:
- `impl From<TokenTree> for TokenStream`
- `impl From<TokenTree> for TreeAndSpacing`
These were useful, but also resulted in code with many `.into()` calls
that was hard to read, particularly for anyone not highly familiar with
the relevant types. This commit makes some other changes to compensate:
- `TokenTree::token()` becomes `TokenTree::token_{alone,joint}()`.
- `TokenStream::token_{alone,joint}()` are added.
- `TokenStream::delimited` is added.
This results in things like this:
```rust
TokenTree::token(token::Semi, stmt.span).into()
```
changing to this:
```rust
TokenStream::token_alone(token::Semi, stmt.span)
```
This makes the type of the result, and its spacing, clearer.
These changes also simplifies `Cursor` and `CursorRef`, because they no longer
need to distinguish between `next` and `next_with_spacing`.
Closes 3245
Closes 3561
These issues were originally linked in issue 3672 and as was mentioned
in PR 3706, it's unclear which commit resolved the issue but the issue
can no longer be reproduced.
Closes 2534
The behavior described in the original issue can no longer be
reproduced. The tests show that to be the case regardless of if
`format_macro_matchers` is `true` or `false`.
* Bugfix: Now slash/start comments aren't duplicated on trait parameters.
* Removing unnecesary comment.
* Improvements: Improving the BytePos offset.
* Improvements: Improving the description of the test cases.
fn_args_layout is now deprecated.
This option was renamed to better communicate that it affects the layout
of parameters in function signatures and not the layout of arguments in
function calls.
Because the `fn_args_layout` is a stable option the renamed option is
also stable, however users who set `fn_args_layout` will get a warning
message letting them know that the option has been renamed.
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.
