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

"mark" rule's autocorrections are eating preceding closing braces #1029

Closed
ChristopherRogers opened this issue Dec 22, 2016 · 5 comments
Closed
Labels
bug Unexpected and reproducible misbehavior.

Comments

@ChristopherRogers
Copy link

ChristopherRogers commented Dec 22, 2016

EDIT: This bug should now be reproducible with the code snippet below as of 0.16.1.

With code like this...

//MARK:- Top-Level bad mark
//MARK:- Another bad mark
struct MarkTest {
}
// MARK:- Bad mark
extension MarkTest {
}

swiftlint autocorrect will transform it into this, eating the closing braces. 😋

// MARK: - Top-Level bad mark// MARK: - Another bad mark
struct MarkTest {
// MARK: - Bad mark
extension MarkTest {
}
@marcelofabri
Copy link
Collaborator

I couldn't reproduce it with 0.14 😬
Are you using the latest version?

@jpsim jpsim added the bug Unexpected and reproducible misbehavior. label Dec 22, 2016
@marcelofabri marcelofabri added the repro-needed Issues that cannot be reproduced or miss proper descriptive examples. label Dec 23, 2016
@jpsim
Copy link
Collaborator

jpsim commented Jan 21, 2017

@ChristopherRogers I'm just following up on @marcelofabri's request for a repro case. If there's a bug here we'd love to know about it!

@ChristopherRogers
Copy link
Author

(Sorry for taking so long to get back; I had been on vacation.)

Sorry, I should've seen if the sample code reproduced the issue first. So, I took a look at the code that was triggering this bug and was able to reduce it to something smaller, which I've placed above. The number of mark comments correlates to the number of characters that are eaten.

The original code doesn't have multiple mark comments on the same type like the code above. Instead it has mark comments placed above methods.

@marcelofabri marcelofabri removed the repro-needed Issues that cannot be reproduced or miss proper descriptive examples. label Jan 23, 2017
@marcelofabri
Copy link
Collaborator

marcelofabri commented Jan 23, 2017

Thanks for the follow up, @ChristopherRogers. I could reproduce it now with 0.16.1.

@kimdv
Copy link
Contributor

kimdv commented Jul 6, 2017

Can still reproduce this in 0.20.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected and reproducible misbehavior.
Projects
None yet
Development

No branches or pull requests

4 participants