[merge] merge viewer always saves with workspace encoding

Observed in Eclipse Neon.3, Xtext 2.13.0.

We have a mixed workspace where some files (actually, some projects) use ISO-8859-1 encoding, while others use UTF-8. Global workspace encoding is set to UTF-8, locale is en_US.UTF8.

This works fine except when there are merge conflicts in an ISO-8859-1 project on a file handled by an Xtext language, when the (default) language-specific "MyDsl compare" is used. The merge viewers (left & right) do show the conflicting file contents fine, and merging works fine, but when the merge viewer is saved, the file ends up being written as UTF-8 (i.e., using the workspace encoding) instead of ISO-8859-1 (the resource-specific encoding). As a result ISO-8859-1 upper-half characters get mangled ("é" becomes "é", ISO-8859-1 0xE9 encoded as UTF-8 0xC3 0xA9).

This does not occur when plain "Text compare" is chosen, and the merge is done using that. But of course that loses all the syntax coloring and syntax validation in the merge viewer.

This is caused by Xtext's DefaultMergeViewer.updateContent(Object ancestor, Object left, Object right), which replaces the original input elements by XtextDocuments.

Now the original input objects are IEncodedStreamContentAccessors, which do know about the resource encoding. XtextDocument, however, doesn't, and thus encoding information is lost there. As a result Eclipse's TextMergeViewer.updateContent() will create a ContributorInfo that falls back to the workspace encoding (ResourcesPlugin.getEncoding(); see L563.

Start in org.eclipse.xtext.ui/compare/DefaultMergeViewer.java, especially updateContent, and compare its inputs with TextMergeViewer.updateContent() and ContributorInfo in org.eclipse.compare. Reproduce the merge using a resource-specific ISO-8859-1 encoding, then verify that saving the syntax-aware viewer preserves that encoding and does not mangle upper-half characters.