You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 7, 2023. It is now read-only.
The current parsing strategy ignores any error produced by clang itself, such as those that result of an invalid command-line argument. In particular, if the clang setup is different than the one expected by this linter, and happens to not support one of the used flag, it will not report anything to the user.
Better behaviours would be to trigger an error message signaling an incompatibility and suggesting fixes to the user (such as upgrading clang), or to retry spawning the clang command without the faulty argument.
However, parsing clang’s errors is made difficult by the fact that both linting errors and errors related to clang are written to the same stream (stderr). I can think of two ideas to address that:
The first solution would be quite simple to setup, but surely less robust than the second one, that would require creating a C/C++ binding. The second solution could bring more responsiveness to the linter.
The text was updated successfully, but these errors were encountered:
The second solution is the only one I've come up with that really seems like it would work, unfortunately it definitely looks like it would require some major re-working of this package from the bit that I've looked into it. There was some initial work in this direction over in the libclang branch, but as the package has mostly been reworked since that branch was last touched it could mostly just serve as an example for future work.
What would be interesting would be to create a separate package which would provide bindings to libclang’s diagnostics. It could then be used by this package and reused by others looking to lint C/C++ code from JavaScript.
If it sounds like a good idea to you, I am willing to work on such a package.
The branch linked above used https://www.npmjs.com/package/libclang, unfortunately that hasn't been touched in 3 years so it's unlikely to still be complete if even usable.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This is a follow-up of #199 (comment).
The current parsing strategy ignores any error produced by clang itself, such as those that result of an invalid command-line argument. In particular, if the clang setup is different than the one expected by this linter, and happens to not support one of the used flag, it will not report anything to the user.
Better behaviours would be to trigger an error message signaling an incompatibility and suggesting fixes to the user (such as upgrading clang), or to retry spawning the clang command without the faulty argument.
However, parsing clang’s errors is made difficult by the fact that both linting errors and errors related to clang are written to the same stream (stderr). I can think of two ideas to address that:
RegExp.exec
loop (at https://github.com/AtomLinter/linter-clang/blob/master/lib/main.js#L325), check if there is still some output from clang that has not been consumed by the regex, and if it starts withclang: error:
;The first solution would be quite simple to setup, but surely less robust than the second one, that would require creating a C/C++ binding. The second solution could bring more responsiveness to the linter.
The text was updated successfully, but these errors were encountered: