-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Check for version control conflict markers #32059
Comments
This comment has been minimized.
This comment has been minimized.
I'm actually quite interested in implementing this. It looks reasonable enough on a cursory glance. My initial approach would likely be modifying the lexer itself and identifying conflict markers there. Seems like the most straight-forward approach given the line-based nature of conflict markers. There are probably a few different behaviours that could be explored (do we continue lexing? attempt to parse using one-conflict etc?) but more discussion is probably required before choosing anything complex. Any suggestions are appreciated. |
That sounds ok to me. Let me know if you have further questions! |
@tiehuis did you make any progress on this? If not, I'd be interesting if giving it a shot myself... |
I have made some progress, but a few things were still left to do. Been a bit inactive, so feel free to take a go. The rough approach I have which may be of some use) is:
|
cc @matklad re. lexer impl. |
Any progress on this? If not, is there a specific blocker, or just a lack of manpower? |
Lack of people working on this |
Partly address rust-lang#32059.
#106242 will address some specific cases, but because it happens in the parser and not the lexer, it doesn't have full coverage for all cases people might encounter, but it does cover a few I thought of. At the very least, a check for where bounds, for ADT bodies and type parsing should be added. The PR also makes no attempt to recover the parser state (even though it potentially could because we're in the parser) because I don't want to deal with the emission of weird errors that might confuse people more than they would help. |
Detect diff markers in the parser Partly address rust-lang#32059.
Detect diff markers in the parser Partly address rust-lang#32059.
Detect diff markers in the parser Partly address rust-lang#32059.
Closing, we can open new tickets if specific cases are found where the current approach doesn't trigger. |
See https://twitter.com/whitequark/status/706091651979083776
If a C file has a version control conflict marker (e.g.
<<<<<<<<< HEAD
or>>>>>>>>>>>>> branch
), clang will helpfully detect it and spit out a more specific parse error. Sounds like something we could be doing too.The text was updated successfully, but these errors were encountered: