Previously we would just treat each merge marker as trivia and then continue
scanning and parsing like normal. This worked well in some scenarios, but
fell down in others like:
```
class C {
public foo() {
<<<<<<< HEAD
this.bar();
}
=======
this.baz();
}
>>>>>>> Branch
public bar() { }
}
```
The problem stems from the previous approach trying to incorporate both branches of the merge into
the final tree. In a case like this, that approach breaks down entirely. The the parser ends up
seeing the close curly in both included sections, and it considers the class finished. Then, it
starts erroring when it encounters "public bar()".
The fix is to only incorporate one of these sections into the tree. Specifically, we only include
the first section. The second sectoin is treated like trivia and does not affect the parse at all.
To make the experience more pleasant we do *lexically* classify the second section. That way it
does not appear as just plain black text in the editor. Instead, it will have appropriate lexicla
classifications for keywords, literals, comments, operators, punctuation, etc. However, any syntactic
or semantic feature will not work in the second block due to this being trivia as far as any feature
is concerned.
This experience is still much better than what we had originally (where merge markers would absolutely)
destroy the parse tree. And it is better than what we checked in last week, which could easily create
a borked tree for many types of merges.
Now, almost all merges should still leave the tree in good shape. All LS features will work in the
first section, and lexical classification will work in the second.
This is necessary for incremental parsing correctness, as the incremental parser
will attempt to reuse these types of nodes in both contexts, and we much ensure
it creates the same trees you would get if you were parsing normally.
Cyrus Najmabadi
Vladimir Matveev
Mohamed Hegazy