Skip to content
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

format_code_in_doc_comments makes multiline comments invalid #4421

Open
vmx opened this issue Sep 10, 2020 · 4 comments
Open

format_code_in_doc_comments makes multiline comments invalid #4421

vmx opened this issue Sep 10, 2020 · 4 comments
Assignees
Labels
a-comments bug Panic, non-idempotency, invalid code, etc. only-with-option requires a non-default option value to reproduce

Comments

@vmx
Copy link

vmx commented Sep 10, 2020

Describe the bug

All this happens only with format_code_in_doc_comments=true.

This is a follow up issue of #4420. When reformatting the output of that issue, another issue occurs. Two subsequent multiline comments (/* */), though in one line each, are transformed to invalid syntax as the opening indicator /* of the second line gets transformed to an asterisk * only.

To Reproduce

I use the (wrong) output from #4420 as basis and make it even more minimal (it can also be reproduced with the full output of that issue). When running the code blow with rustfmt --config format_code_in_doc_comments=true

enum Minimal {
    /* thatsleft */
    /* canbeanything */
}

The output is:

enum Minimal {
    /* thatsleft */
 * canbeanything */}

That is even invalid syntax.

Expected behavior

I would expect that the code is untouched by rustfmt.

Meta

  • rustfmt version: rustfmt 1.4.18-nightly (c1e9b7b 2020-06-13)
  • From where did you install rustfmt?: rustup
  • How do you run rustfmt: rustfmt, but it also happens with cargo fmt
@vmx vmx added the bug Panic, non-idempotency, invalid code, etc. label Sep 10, 2020
@calebcartwright calebcartwright added a-comments only-with-option requires a non-default option value to reproduce labels Sep 12, 2020
@ytmimi
Copy link
Contributor

ytmimi commented Jul 26, 2022

confirming this is reproducible with rustfmt 1.5.1-nightly (9c8ccc32 2022-07-26)

Linking tracking issue for format_code_in_doc_comments #3348

@CosmicHorrorDev
Copy link
Contributor

@rustbot claim

@CosmicHorrorDev
Copy link
Contributor

Had some time to look into this today. It seems like the root cause is that the rewriting is pretty messy in terms of determining separation of comments when block comment are involved. This also includes issues with the normalize_comments config since it shares the same rewriting logic. Here's a more elaborate example

enum Original {
    /* foo */
    /* bar */
}

enum DocComments {
    /** foo */
    /** bar */
    Variant,
}

enum Mix {
    // inline /* still inline */
    /* block1 */ /* block2 */
    Foo,
    /* block */
    // inline
    /* block */
    Bar,
}

With format_code_in_doc_comments=true

enum Original {
    /* foo */
     * bar */
}

enum DocComments {
    /** foo */
     * bar */
    Variant,
}

enum Mix {
    // inline /* still inline */
    /* block1 */ /* block2 */
    Foo,
    /* block */
     * inline
     * block */
    Bar,
}

With normalize_comments=true

enum Original {
    // foo */
    // bar
}

enum DocComments {
    /// foo */
    /// bar
    Variant,
}

enum Mix {
    // inline /* still inline */
    // block1 */ /* block2
    Foo,
    // block */
    // inline
    // block
    Bar,
}

It seems like the solution is properly handling parsing where comments start and end. That's all I have time for today though

@CosmicHorrorDev
Copy link
Contributor

From poking around it looks like #5306 fixes all of the issues when using normalize_comments=true except for leaving */ /* when using multiple block comments in the same line, but doesn't fix any of the issues for format_code_in_doc_comments=true. It's possible that some small tweaks on top of that PR could also resolve this issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a-comments bug Panic, non-idempotency, invalid code, etc. only-with-option requires a non-default option value to reproduce
Projects
None yet
Development

No branches or pull requests

4 participants