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

Emitted warnings/errors should include a column number #2267

Closed
1 of 2 tasks
lilyball opened this issue Jun 25, 2018 · 8 comments
Closed
1 of 2 tasks

Emitted warnings/errors should include a column number #2267

lilyball opened this issue Jun 25, 2018 · 8 comments
Labels
enhancement Ideas for improvements of existing features and rules.

Comments

@lilyball
Copy link

New Issue Checklist

Bug Report

The output of SwiftLint is of the form

/path/to/file:15: warning: message goes here

Unfortunately, this doesn't play well with xcpretty, as xcpretty appears to require a column number for warnings (filed as xcpretty/xcpretty#321). It would be great if SwiftLint could start including column numbers so the output would be

/path/to/file:15:23: warning: message goes here

Environment

  • SwiftLint version 0.25.1
@realm-probot realm-probot bot added the O:User label Jun 25, 2018
@marcelofabri
Copy link
Collaborator

The Xcode formatter prints the column if it's available: https://github.com/realm/SwiftLint/blob/master/Source/SwiftLintFramework/Reporters/XcodeReporter.swift#L14

Maybe some rules are not setting it (only line). Is this happening to a particular rule?

@lilyball
Copy link
Author

Right now I'm reproducing it with the vertical_whitespace rule.

@lilyball
Copy link
Author

Looks like the xcpretty issue is more than just column, it also wants the "cursor" output that compilers include. I'll file a separate issue about that.

@lilyball
Copy link
Author

Filed as #2268 (though the lack of a column is also important here).

@marcelofabri marcelofabri added the enhancement Ideas for improvements of existing features and rules. label Jul 1, 2018
@jpsim
Copy link
Collaborator

jpsim commented Nov 27, 2018

I wonder if there would be any negative ramifications of using a fallback column of 1 if there's none provided. This would be very easy to do.

@lilyball
Copy link
Author

Probably very minimal. You could also use a column of 0 to signify that there is no column information (similar to how Swift backtraces use a line number of 0 for generated code that has no associated source line).

@jpsim
Copy link
Collaborator

jpsim commented Nov 27, 2018

Went with a fallback column value of 1 like we do for line numbers. At least this way the location is a valid location in the file. Seems safer. #2488

@jpsim
Copy link
Collaborator

jpsim commented Nov 27, 2018

Addressed in #2488.

@jpsim jpsim closed this as completed Nov 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Ideas for improvements of existing features and rules.
Projects
None yet
Development

No branches or pull requests

3 participants