Skip to content

Comments between assignment (without let) lhs and rhs handling #4661

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

Conversation

davidBar-On
Copy link
Contributor

Add handling of comments between assignment (without let) lhs and rhs by using rewrite_assign_rhs_with_comments() (one of the cases identified in #4626 discussion).

Copy link
Member

@calebcartwright calebcartwright left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this! Looks pretty good, few minor comments left inline

Comment on lines 1898 to 1905
let span_hi = rhs.span.lo();
let (operator_str, span_lo) = match op {
Some(op) => (context.snippet(op.span), op.span.hi()),
None => {
let lo = lhs.span.hi();
let offset = context.snippet(mk_sp(lo, span_hi)).find_uncommented("=")? + 1;
("=", lo + BytePos(offset as u32))
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be remembering incorrectly, but I believe the AST nodes for assignment expressions actually contain the span for the operator or binop. Could you double check that (presumably back at the call sites), and if it's there then update our destructuring code to grab it?

Would much rather plug and play from the AST than recalculating spans when possible

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there is such span. Changed the code to use it.

let var = /* Block comment longgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg */ first;
var /= /* Block comment longgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg */ second;
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solid test suite! For the sake of extreme thoroughness, do you think it'd be worthwhile to add a multiline blockstyle comment case?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added multiline comments test cases.

However, I think there is an issue with the multiline comments formatting by combine_strs_with_missing_comments() (not caused by this PR so I didn't try to fix it here). An example of the issue is that the following formatted code:

let var = /* Block comment line 1
    * Block comment line 2 */
    first;

Should probably have been either:

let var = /* Block comment line 1
           * Block comment line 2 */
    first;

or:

let var = /* Block comment line 1
           * Block comment line 2 */  first;

Is this really an issue? If yes, which of the output versions is desired? If this is an issue that should be fixed, I can try to do that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really an issue?

it is an issue yes. some of these comment edge cases can be so exhausting sometimes 😄 it would have to be the former or what we did in other similar scenarios

e.g. something like this (hand typed to give a visual, indentation may be off)

let var = 
    /* Block comment line 1
     * Block comment line 2 */
    first;

I'd prefer the former in the spirit of maintaining developer defined comment association, as odd as such a comment would be in these types of local cases.

@calebcartwright
Copy link
Member

Also be sure to rebase to pull in the rustc-ap crate updates

@davidBar-On davidBar-On force-pushed the lhs-to-rhs-bewteen-comments-assignment branch from 4522b75 to 24e632e Compare February 27, 2021 09:00
@calebcartwright
Copy link
Member

I am going to go ahead and merge this in the spirit of moving forward, though want to make a note of how it would potentially be problematic in the 1.x case.

Currently, in the presence of such comments rustfmt will bail and leave the original formatting in place, but with this change rustfmt will of course reformat all such cases. The multi-line block style comment that opens on the same line as the operator would be problematic though as however unlikely that actually is in practice, we'd be emitting formatting that's off which the user would be unable to correct.

Only going to merge here because it's against the master branch and it's such an extreme edge case that we'll get sorted quickly anyway. Let's prioritize getting that edge case resolved though 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants