Linter rule prefer_adjacent_string_concatenation conflicts with no_adjacent_strings_in_list

[quoc-huynh-cosee]

Describe the issue
I have e.g. a very long string in a list, which I need to splite into separate parts (to avoid lines longer than 80 characters). If I try to do this using the + I'm receiving the prefer_adjacent_string_concatenation warning.

To Reproduce
The following code gives me a lint warning prefer_adjacent_string_concatenation.

final myList = [
  'very long string' +
    'continue very long string'
]

But doing this with the quick fix, I'm receiving no_adjacent_strings_in_list.

final myList = [
  'very long string' 
    'continue very long string'
]

Expected behavior
The linter won't raise the warning prefer_adjacent_string_concatenation in lists.

[srawlins]

We may just want to document that these two rules conflict. Or we may want prefer_adjacent_string_concatenation to allow + in a list.

[bwilkerson]

Maybe only allow it when no_adjacent_strings_in_list is enabled, and then document the interactions between the two lints?

[srawlins]

I believe that the two rules satisfy good practices:

• prefer_adjacent_string_concatenation is a style-oriented rule, but it is in the recommended set. So... it is recommended.
• no_adjacent_strings_in_list is an error-preventing lint rule. When you write var x = ['a' 'b', 'c'];, the formatter will not change that text. Same with var x = [if (1 == 2) 'a' 'b', 'c'];. So the rule is designed to prevent bugs where a comma was accidentally omitted.

Because of that, I don't think the implementation of either rule should conflict with the other. We should not make users choose between one recommended practice and one safe practice.

I think as far as prefer_adjacent_string_concatenation goes, it should definitely allow addition (+) for strings in collection literals, to help prevent the bugs that no_adjacent_strings_in_list prevents.

@pq @bwilkerson

[pq]

/fyi @lrhn @jakemac53 @munificent @natebosch @goderbauer (who may have interest since this is in the recommended set)

[lrhn]

I'd do what @bwilkerson said above: allow + only if the no_adjacent_strings_in_list lint is enabled.

We should guarantee that the + is handled efficiently (behaves like adjacent string literals, not doing repeated runtime consternation).

[munificent]

• When you write var x = ['a' 'b', 'c'];, the formatter will not change that text.

This is true of the current formatter, but the upcoming style will give you:

var x = [
  'a'
      'b',
  'c',
];

The new formatter always splits between adjacent strings.

[srawlins]

Thanks, Bob!

Ok with that, I don't think we need to go through hoops to support no_adjacent_strings_in_list. It's not a recommended rule, and only targets (will only target) error-prone adjacent strings in non-formatted code. We can just declare the rules incompatible, in lieu of supporting "lint configuration based on what other lint rules are enabled."

[srawlins]

Fixed with 6c5a9e4