roslyn: Roslyn C#/VB should detect Git-style merge conflicts and be resilient to them in editing scenarios.
In TypeScript, I augmented the scanner/parser to detect the git-style merge conflict of:
<<<<< HEAD
code
====
code
>>>> Blah
I then treated this similarly to how C#/VB handle #if #else #endif. Namely, the first part is properly scanned/parsed, and the second part is treated as Inactive-Code.
I also tweaked the classifier so that we do lexical classification in the lower branch of the merge conflict.
This provided a great editing experience around Git conflicts. First off, if you do this, the parser doesn’t go off the rails like it does today. Everything remains nicely parseable. Second, editing in the top section works just as normal. You get intellisense, goto-def, etc. Editing in the bottom section is just like editing inside a comment. Nothing gets in your way (like today, where the parser confusion makes everything bad). And things still look pretty good as lexical classification does a decent enough job in that section.
I think we should bring this over to C#/VB to make the experience here much better.
About this issue
- Original URL
- State: closed
- Created 9 years ago
- Comments: 15 (13 by maintainers)
@CyrusNajmabadi Thanks for doing this. You are awesome.
I’m not. This was a boon to TypeScript and has not been a problem there at all.
No. Why would it need to be?
Yes. There is a specific syntax kind for these entities: SyntaxKind.ConflictMarker.
–
Think about it this way:
The code is deeply in error. Instead of the current situation, where the parsers completely lose it, and the rest of the system then gets dragged down, we instead detect the error early and produce a very good tree for it. This has nothing to do with the languages themselves. Instead, it’s entirely about the tooling detecting and dealing with a common error situation.