Repository navigation
idea: consult git diff for better diagnostics / syntax errors #48911
Description
Just an idea:
Let's say our code looks like this:
fn main() {
{
{
{
println!("Hello, world!");
}
}
}The error message is not very helpful here, pointing to lines 1 and 8:
error: this file contains an un-closed delimiter
--> src/main.rs:8:3
|
8 | }
| ^
|
help: did you mean to close this delimiter?
--> src/main.rs:1:11
|
1 | fn main() {
| ^
However, since cargo inits new repos as git repo, maybe we can utilize the repo diff and see which brace was added the last:
fn main() {
{
{
- println!("Hello, world!");
+ {
+ println!("Hello, world!");
}
}
}and give a better diagnostic:
error: this file contains an un-closed delimiter
--> src/main.rs:8:3
|
8 | }
| ^
|
help: did you mean to close this delimiter?
--> src/main.rs:4:12
|
4 | {
| ^
```
Reacted by LifeIsStrange and Bobbywan-Roboyo
Reacted by Zack M. Davis
Activity
zackmdavis commentedon Mar 10, 2018
Not worth the extra complexity, I would argue: teaching
rustcto parse and interpret Git diffs would be just too large of dependency relative to the benefit of being able to provide a smarter error message in one particular case if the user happens to be using Git and the working tree has few enough changes from the last commit for us to be able to infer intent.Songbird0 commentedon Mar 10, 2018
Maybe add this feature as "optional" analytic process? Unless, of course, there aren't other scenarios where this may be useful.
Ixrec commentedon Mar 15, 2018
For the specific case of curly brace matching errors, I think the indentation of the braces would be a far better heuristic for user intent than git history. The reason the opening brace on line 4 is "obviously" the unmatched one is because no other curly brace in the example has the same indentation. I'm not sure how to generalize that rule so it works on non-trivial examples, but it seems solvable.
(personally, it's not obvious to me that there are any situations where rustc looking at git history could lead to a significantly better error message, much less enough situations to justify the dependency)
estebank commentedon Sep 14, 2018
#53949 analyses the indentation of unmatched braces to provide appropriate suggestions and #54029 will provide further suggestions. I find that relying on the version control system to supply suggestions is an intriguing proposition, but unlikely to be pursued in the medium term.
tromey commentedon Sep 14, 2018
One related thing that gcc and clang do is notice conflict markers from
patchand emit a nicer error in that situation, like:zackmdavis commentedon Sep 14, 2018
(This is #32059.)
estebank commentedon Jan 26, 2019
Closing as #53949 addresses the mismatched braces issue for reasonably formatted code (and there's already another ticket for version control conflict markers). We're unlikely to ever ship with an implementation of
gitin the compiler.