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
kballard opened this Issue Jun 25, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@kballard
Copy link

kballard commented Jun 25, 2018

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

This comment has been minimized.

Copy link
Collaborator

marcelofabri commented Jun 25, 2018

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?

@kballard

This comment has been minimized.

Copy link

kballard commented Jun 25, 2018

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

@kballard

This comment has been minimized.

Copy link

kballard commented Jun 25, 2018

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.

@kballard

This comment has been minimized.

Copy link

kballard commented Jun 25, 2018

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

@jpsim

This comment has been minimized.

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.

@kballard

This comment has been minimized.

Copy link

kballard commented Nov 27, 2018

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

This comment has been minimized.

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

This comment has been minimized.

Copy link
Collaborator

jpsim commented Nov 27, 2018

Addressed in #2488.

@jpsim jpsim closed this Nov 27, 2018

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