Deal with eol in Windows for Xtend generated files with simple multiline strings

[LorenzoBettini]

That's related to the discussion eclipse/xtext#2135 (comment)

   var Sring s = "so simple
       so multiline";

In Windows, Xtend generates a Java string with \r\n.

@szarnekow suggests we force unix line handling when cloning the Git repository in Windows.
@merks, is there a way to configure Oomph accordingly?

@szarnekow concerning your comment eclipse/xtext#2135 (comment) do you think it would be feasible to manually remove \r after calling convertToJavaString (I mean, a simple .replace("\r", ""))? Java text blocks are ensured never to contain \r, since the compiler strips them. Would that be a breaking change?

[merks]

You can paste this onto your git clone task to override Oomph's git clone task adding this property set to true:

<?xml version="1.0" encoding="UTF-8"?>
<git:ConfigSection
    xmi:version="2.0"
    xmlns:xmi="http://www.omg.org/XMI"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:git="http://www.eclipse.org/oomph/setup/git/1.0"
    xsi:schemaLocation="http://www.eclipse.org/oomph/setup/git/1.0 http://git.eclipse.org/c/oomph/org.eclipse.oomph.git/plain/setups/models/Git.ecore"
    name="core">
  <properties
      key="autocrlf"
      value="input"/>
</git:ConfigSection>

I'd avoid setting it to false, because it's all too easy to check-in windows line endings into the git repository messing up with others see on mac/linux...

(Good generators should respect workspace preferences and/or preserve what's used in already-present files. It's easy to overlook this when you aren't developing on or for Windows.)

[cdietrich]

does the checkout really help
see also
eclipse/xtext#2293

[szarnekow]

Good generators should respect workspace prefs

The Xtext / Xtend compiler infra does that. But: String literals are taken literally - it's a sequence of chars. If that sequence contains a \r\n it will be in the compiled string literal. In hindsight, the Java choice for multi-line strings is probably better since more opinionated and machine independent. We didn't do that in Xbase / Xtend.

If the repository contains \n line-breaks and we check these out into the working copy as is, the generated code will be stable.

[LorenzoBettini]

@cdietrich indeed my feeling is that the git setting would work only for the checkout: modifying the source later will lead to the same problem, that's why I was suggesting to do the preprocessing removing \r in Xtend. Let's see what @szarnekow . In that issue he was also suggesting to adhere with Java code blocks eclipse/xtext#2293

[szarnekow]

Yes, that would be a separate compiler setting, though.

[LorenzoBettini]

@szarnekow so you're suggesting introducing a new Xtend compiler setting to decide whether to remove \r?

[szarnekow]

@szarnekow so you're suggesting introducing a new Xtend compiler setting to decide whether to remove \r?

Maybe. First, I need to understand the real problem.
We certainly don't want to remove a \r if the Xtend code contained that exact sequence, e.g., something like var CR = ' \r'. That would be quite sad.

[merks]

I think the (a?) fundamental problem is that org.eclipse.xtend2.lib.StringConcatenation.DEFAULT_LINE_DELIMITER uses org.eclipse.xtend2.lib.DefaultLineDelimiter.get() which simply does this:

return System.getProperty("line.separator");

So on Windows such things will generate \r\n always so I'm not sure how forcing linux endings in the clone will help...

[szarnekow]

That property is used at runtime only and not by the Xbase compiler itself. It's all a bit confusing.

E.g. the Xbase compiler use the TreeAppendable abstraction which is initialized like this:

val appendable = new TreeAppendable(importManager, cachingConverter, locationProvider, jvmModelAssociations, context, " ", "\n")

You see how it uses unix line endings by default. Subsequently it funnels the result through UnicodeAwarePostProcessor which reads the getLineSeparatorInformation from the project (in Eclipse) and replaces the UNIX line endings by the project specific line endings. All this doesn't matter for plain string literals.

Note that a string literal in the model is exactly that: a literal. It's an array of chars. The compiler is not in the position to judge that array. If it contains a carriage return, it needs to go into the class file.

[LorenzoBettini]

@szarnekow probably, my solution is oversimplistic because I wasn't considering \r intentionally inserted. I was thinking about strings that span multiple lines, but again you cannot distinguish between characters EOL inserted by the user intentionally.

I was thinking about Java text blocks where it is the compiler stripping \r, but Java text blocks must span multiple lines so in that case the semantics is clear.