-
-
Notifications
You must be signed in to change notification settings - Fork 19
rustc invocation does not work with panic=abort configurations #47
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
Comments
Errors reported by rustc may not have any associated position in a file, for instance if the error is related to the project as a whole (see flycheck/flycheck-rust#47). Previously, we did not collect any error without spans, thus not only misreporting errors from rustc, but also raising a suspicious checker state. This commit enhances `flycheck-parse-rust` to collect errors without associated spans. By default, these errors are bound to the position (0,0) of the current buffer.
When I try the above settings on a test crate, I can indeed reproduce the issue. Thanks for the report 👍
Regardless, we should be able to report the error as-is in Flycheck. It seems the suspicious state stems from not collecting errors that have empty spans (no filename info). I've sent a PR which should fix this issue. |
Errors reported by rustc may not have any associated position in a file, for instance if the error is related to the project as a whole (see flycheck/flycheck-rust#47). Previously, we did not collect any error without spans, thus not only misreporting errors from rustc, but also raising a suspicious checker state. This commit enhances `flycheck-parse-rust` to collect errors without associated spans. By default, these errors are bound to the position (0,0) of the current buffer.
Fixed in flycheck/flycheck#1182. |
I have a rust project that contains the following in its Cargo.toml:
The command that gets run is:
This can't be parsed by flycheck:
The text was updated successfully, but these errors were encountered: