[analyzer] `prefer_final_locals` incorrectly handles join pattern variables

[incendial]

Hi,

void fn(Object val) {
  if (val case SomeClass(:var value) || SomeClass(:var value)) { // <-- incorrectly suggests to use final
    value = 'str';
  }
}

void anotherFn() {
  var val = 1; // <-- works correctly, does NOT suggest final
  val = 3;
}

class SomeClass {
  final String value;

  const SomeClass(this.value);
}

Dart SDK version: 3.8.1 (stable) (Wed May 28 00:47:25 2025 -0700) on "macos_arm64"

[FMorschel]

I'll take a look at this one too. Thanks for the report!

[eernstg]

Random drive-by comment: That's a tricky one because each occurrence of var value in the pattern introduces a new variable, and the block statement which is the body of the if statement has a single variable that "stands in" for all the variables that are introduced by the pattern (and it is initialized with the value of the one whose branch was actually part of the successful match).

So the lint probably doesn't see any assignments to each of those two pattern-declared variables because there are none, so it recommends that each of them is made final.

However, the analysis does see that the extra variable named value which is implicitly introduced in the body of the if statement is getting mutated. That in turn is an error if we have made the two pattern variables final, because the implicit body variable gets the same modifier (final or not) based on the modifiers of all the pattern variables that have the same name (and it's an error if they disagree on the finality or type).

So the lint would need to detect the sharing, as in "this pattern-declared variable can't be final because it is associated with that implicit body variable, which is being mutated".

[incendial]

AFAIK, JoinPatternVariableElement already has this info https://github.com/dart-lang/sdk/blob/main/pkg/analyzer/lib/dart/element/element.dart#L2568

And the bug is probably related to JoinPatternVariableElement being stored as a usage instead of its variables.

[eernstg]

Sounds right, thanks!

[FMorschel]

Yes, @incendial is correct. I've fixed some other issues with Go to definition and occurrences for these previously (#60398 - the issue is still open because of a discussion about changing that structure), so I'm familiar with this.

[FMorschel]

Here is the CL https://dart-review.googlesource.com/c/sdk/+/453101