`dart fix` applies fixes in part files mutliple times

[denniskaselow]

Dart SDK version: 3.7.0-157.0.dev (dev) (Sat Nov 16 12:03:16 2024 -0800) on "windows_x64"

Running dart fix --apply on this code will apply the fixes in b.dart multiple times:

// a.dart
part 'b.dart';

void a() {
  // need to trigger a lint in a.dart for the bug to happen
  ;
  b();
}

// b.dart
part of 'a.dart';

Stream<String> b() {
  // dart fix should only add a single const
  return Stream.empty();
}

# analysis_options.yaml
linter:
  rules:
    - empty_statements
    - prefer_const_constructors

The fix adds const 3 times in b.dart:

part of 'a.dart';

Stream<String> b() {
  // dart fix should only add a single const
  return const const const Stream.empty();
}

Output of dart fix --apply:

Applying fixes...

lib\a.dart
  empty_statements • 1 fix

lib\b.dart
  prefer_const_constructors • 3 fixes

It's not limited to these lints. For example the fix for require_trailing_commas would add multiple commas.

[pq]

/fyi @bwilkerson

[bwilkerson]

Is this a recent regression?

[benthillerkus]

from the issue i had opened today:

• This bug is now in the latest Flutter release
• Repro https://github.com/benthillerkus/dart_fix_repro

[pq]

Working on reproducing this in https://dart-review.googlesource.com/c/sdk/+/401180, I'm not seeing it at the bulk_fix level in the server but it does reproduce in the fix command. My thinking is there's something funny going on in how we're detecting when another fix iteration is required?

/fyi @bwilkerson

[pq]

Hmmmm, or maybe not quite. Reducing maxPasses to 1, I still see the fix doubly-applied:

00:00 +0 ~13 -1: fix perform --apply --code=(multiple) [part file] [E]

  Expected: (a string containing 'Applying fixes...', 'lib/main.dart', '  empty_statements • 1 fix', 'lib/part.dart', '  prefer_const_constructors • 1 fix', '2 fixes made in 2 files.' in order or a string containing 'Applying fixes...', 'lib/main.dart', '  empty_statements - 1 fix', 'lib/part.dart', '  prefer_const_constructors - 1 fix', '2 fixes made in 2 files.' in order)
    Actual: 'Computing fixes in myapp...\n'
              'Applying fixes...\n'
              '\n'
              'lib/main.dart\n'
              '  empty_statements - 1 fix\n'
              '\n'
              'lib/part.dart\n'
              '  prefer_const_constructors - 2 fixes\n'
              '\n'
              '3 fixes made in 2 files.\n'
              ''

Interestingly, with the default of 4 maxPasses we're only seeing one more over-application:

00:01 +0 ~13 -1: fix perform --apply --code=(multiple) [part file] [E]

  Expected: (a string containing 'Applying fixes...', 'lib/main.dart', '  empty_statements • 1 fix', 'lib/part.dart', '  prefer_const_constructors • 1 fix', '2 fixes made in 2 files.' in order or a string containing 'Applying fixes...', 'lib/main.dart', '  empty_statements - 1 fix', 'lib/part.dart', '  prefer_const_constructors - 1 fix', '2 fixes made in 2 files.' in order)
    Actual: 'Computing fixes in myapp...\n'
              'Applying fixes...\n'
              '\n'
              'lib/main.dart\n'
              '  empty_statements - 1 fix\n'
              '\n'
              'lib/part.dart\n'
              '  prefer_const_constructors - 3 fixes\n'
              '\n'
              '4 fixes made in 2 files.\n'
              ''

[FMorschel]

My guess (I've not looked into anything) is that this has something to do with the new element model/enhanced parts changes. Maybe some of the new logic with that was already on that version for the analysis done here?

[pq]

@FMorschel: totally and that's my thinking too but I haven't found what level the problem is occurring in. (Unfortunately, the only place I have it reproduced, in the dart fix tests is hard to debug since the tests spawn a process and can't just be stepped through.) I'll keep digging though. Thanks!