Automatic literal String concatenation breaks annotation literals

[quietopus]

In most contexts, when I specify a long String like this:

String jacksNovel = 'All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy.';

The editor may automatically replace the String literal with a literal concatenation, similar to this:

String jacksNovel = 'All work and no play makes Jack a dull boy. ' +
                    'All work and no play makes Jack a dull boy. ' +
                    'All work and no play makes Jack a dull boy.';

When specifying a String literal as an annotation parameter, however, there is no valid concatenation syntax (that I am aware of). Nonetheless, the above syntax is applied whenever I edit a long String in an Annotation. So this:

@InvocableVariable(
  Label='Jacks Novel'
  Description='All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy. All work and no play makes Jack a dull boy.'
)  

Automatically becomes this:

@InvocableVariable(
  Label='Jacks Novel'
  Description='All work and no play makes Jack a dull boy. ' +
              'All work and no play makes Jack a dull boy. ' + 
              'All work and no play makes Jack a dull boy.'
)

The concatenation above is invalid and produces a Syntax error. It also comes back whenever I touch the Description property.

[Scott Wells]

Thanks for filing. I'll take a look for the next build.

[Scott Wells]

I apologize but perhaps I’m misunderstanding the issue. It’s true that if you type Enter in the middle of an Apex string literal, IC2 converts the literal into a string concatenation expression, but for a string literal used as an annotation parameter value, an error message is clearly displayed in the Apex editor indicating that you have invalid syntax. That way the user is told without having to deploy that deployment would fail, albeit with a different error message issued by the Salesforce Apex compiler than by IC2’s local Apex parser.

Just for clarification, is the concern that Enter has that behavior at all in this situation – converting the literal into a concatenation expression – or are you seeing some other problem that I’ve not described above?

[quietopus]

No worries, thanks for checking! It’s a different issue. The concatenation does not happen when you press Enter in the middle of the String. Rather, it seemingly happens in order to keep the string shorter than the configured wrapping boundary (I’m not sure what setting that is). So, when the String is exceptionally long, as in the example, IntelliJ will “wrap” the string by converting it into a concatenation of shorter strings. This happens when any change at all is made to the String, regardless of whether that change expresses an intent to split the string, as when the Enter key is pressed. For example, changing the name from “Jack” to “John Jacob Jingleheimer Schmidt” would trigger this issue, provided that the resulting String is long enough.

[Scott Wells]

Oh, that’s very strange. I’m not aware of any formatter option that would do that, and I’m not seeing that behavior myself locally. Can you export your project’s code style and attach it here so I can try to figure out what option might be enabled that would produce that behavior?

[quietopus]

It seems to be affected by the Wrap on typing option under Editor > Code Style. Unchecking that option seems to turn off the automatic splitting. The Hard wrap at value to the left of it impacts the line position at which the String gets split.

If this does not clarify, let me know and I’ll export the full settings.

[Scott Wells]

That’s very helpful. Thanks. I’ll see if I can reproduce it (can’t imagine that I won’t be able to) and then see if there’s any way I can veto automatic Apex string concatenation in contexts where that would result in invalid code. Thanks again for providing all of the context!

[Scott Wells]

At a glance I’m not seeing an obvious way to “veto” automatic hard wraps via a plugin extension point, but I’ve asked JetBrains if there’s something I might be overlooking. Hopefully so, but I’ll provide an update here either way once I have the definitive answer.

[Scott Wells]

Okay, I figured it out and have committed a fix for the next build. The fix is actually more generalized and should address all contexts in which a single string literal is required and a string concatenation expression is not allowed, specifically annotation attribute values, switch when literals, and SOQL/SOSL queries.

[Scott Wells]

Delivered in 2.2.9.3.