Resolves 4615
Previously only Vertical and Mixed enum variants of DefinitiveListTactic
were considered when rewriting pre-comments for inner items in
lists::write_list.
Because we failed to considering the SpecialMacro variant we ended up in
a scenario where a ListItem with a pre_comment and a pre_comment_style
of ListItemCommentStyle::DifferentLine was written on the same line as the
list item itself.
Now we apply the same pre-comment formatting to SpecialMacro, Vertical,
and Mixed variants of DefinitiveListTactic.
Resolves 5009
For loops represented by a ControlFlow object use " in" as their connector.
rustfmt searches for the first uncommented occurrence of the word "in" within the
current span and adjusts it's starting point to look for comments right after that.
visually this looks like this:
rustfmt starts looking for comments here
|
V
for x in /* ... */ 0..1 {}
This works well in most cases, however when the pattern also contains
the word "in", this leads to issues.
rustfmt starts looking for comments here
|
V
for in_here in /* ... */ 0..1 {}
-------
pattern
In order to correctly identify the connector, the new approach first
updates the span to start after the pattern and then searches for the
first uncommented occurrence of "in".
Resolves 5011
Tuple structs with visibility modifiers and comments before the first
field were incorrectly formatted. Comments would duplicate part of the
visibility modifier and struct name.
When trying to parse the tuple fields the ``items::Context`` searches
for the opening '(', but because the visibility modifier introduces
another '(' -- for example ``pub(crate)`` -- the parsing gets messed up.
Now the span is adjusted to start after the struct identifier, or after
any generics. Adjusting the span in this way ensures that the
``items::Contex`` will correctly find the tuple fields.
rustfmt should only support rewriting a struct in an expression
position with alignment (non-default behavior) when there is no rest
(with or without a base) and all of the fields are non-shorthand.
Fixes 4984
When parsing derive attributes we're only concerned about the traits
and comments listed between the opening and closing parentheses.
Derive attribute spans currently start at the '#'.
Span starts here
|
v
#[derive(...)]
After this update the derive spans start after the opening '('.
Span starts here
|
V
#[derive(...)]
This is a copy of #4296 with these changes:
* file is not reopened again to find if the file is generated
* first five lines are scanned for `@generated` marker instead of one
* no attempt is made to only search for marker in comments
`@generated` marker is used by certain tools to understand that the
file is generated, so it should be treated differently than a file
written by a human:
* linters should not be invoked on these files,
* diffs in these files are less important,
* and these files should not be reformatted.
This PR proposes builtin support for `@generated` marker.
I have not found a standard for a generated file marker, but:
* Facebook [uses `@generated` marker](https://tinyurl.com/fb-generated)
* Phabricator tool which was spawned from Facebook internal tool
[also understands `@generated` marker](https://git.io/JnVHa)
* Cargo inserts `@generated` marker into [generated Cargo.lock files](https://git.io/JnVHP)
My personal story is that rust-protobuf project which I maintain
was broken twice because of incompatibilities/bugs in rustfmt marker
handling: [one](https://github.com/stepancheg/rust-protobuf/issues/493),
[two](https://github.com/stepancheg/rust-protobuf/issues/551).
(Also, rust-protobuf started generating `@generated` marker
[6 years ago](https://git.io/JnV5h)).
While rustfmt AST markers are useful to apply to a certain AST
elements, disable whole-file-at-once all-tools-at-once text level
marker might be easier to use and more reliable for generated code.
Added test covering this. Chose to treat the code block
as rust if and only if all of the comma-separated attributes
are rust-valid. Chose to allow/preserve whitespace around commas
Fixes#3158
- [x] Removed `?const` and change uses of `?const`
- [x] Added `~const` to the AST. It is gated behind const_trait_impl.
- [x] Validate `~const` in ast_validation.
- [ ] Add enum `BoundConstness` to the HIR. (With variants `NotConst` and
`ConstIfConst` allowing future extensions)
- [ ] Adjust trait selection and pre-existing code to use `BoundConstness`.
- [ ] Optional steps (*for this PR, obviously*)
- [ ] Fix#88155
- [ ] Do something with constness bounds in chalk
In the event a pattern starts with a leading pipe
the pattern span will contain, and begin with, the pipe.
This updates the process to see if a match arm contains
a leading pipe by leveraging this recent(ish) change to
the patterns in the AST, and avoids an indexing bug that
occurs when a pattern starts with a non-ascii char in the
old implementation.
