-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix failure with line comment following ..
in a struct pattern
#6117
base: master
Are you sure you want to change the base?
Conversation
A little side note here. While making this patch, I noticed some counter-intuitive details in the old implementation. To be specific, the old one uses the fields of the struct without the Foo {
a, ..
} The following are two examples from previous issues. Currently the
match *token {
Token::Dimension {
value, ref unit, ..
} if num_context.is_ok(context.parsing_mode, value) => {
return NoCalcLength::parse_dimension(context, value, unit)
.map(LengthOrPercentage::Length)
.map_err(|()| location.new_unexpected_token_error(token.clone()));
}
}
let Foo {
a, ..
} = b; And if the merge fails due to constraints like let Foo {
a,
..
} = b; I believe there should be a more specific way to determine when to use the mixed tactic, rather than the confusing way of determining the tactic without the |
@mousany I haven't had a chance to review these changes yet, but I wanted to let you know that we strongly discourage merge commits. Please rebase on the latest master when you have a moment. |
@ytmimi I've rebased to the latest master now |
e50e7e5
to
f6a0c3c
Compare
Fixes #6040
When a struct pattern that contained a
..
was formatted, it failed to consider the case when there is line comment following it. Instead it produced a formatting error because it realizes that if it went ahead with the rewirte it would remove the line comment.Now, the following line comment is taken into consideration by adopting the approach to
rewrite_struct_lit
, which is a similar function, for rewriting structs, but doesn't seem to suffer from this trailing comment problem becauserewrite_struct_lit
considers the..
as part of the struct fields that it needs to rewrite.