Prefer late over null-initialized debug fields and enable the lint rule - #192438

The current implementation of lazy_initialized_debug_expensive_fields only checks if the field is static or late. However, if a late field is declared without an initializer, it is not truly lazy-initialized on first read (as there is no initializer to evaluate). Instead, it must be explicitly assigned elsewhere. If this assignment occurs in a non-assert block, it will execute in release/profile builds, defeating the purpose of the @_debugOnly annotation. To prevent this, we should also require that any @_debugOnly field has an initializer.

    // A field is lazy when it's static or late, and has an initializer.
    final bool eagerlyInitialized = hasDebugOnly &&
        (!(node.isStatic || node.fields.isLate) ||
            node.fields.variables.any((VariableDeclaration v) => v.initializer == null));
    if (eagerlyInitialized) {
      rule.reportAtNode(node);
    }

The goal of this rule is just to make sure nothing is eagerly initialized.

To ensure that late fields without an initializer are correctly flagged by the analyzer rule, we should add a test case to lazy_initialized_debug_expensive_fields_test.dart and assert that it produces the expected diagnostic.

  static const String source = '''
class GoodClass {
  @_debugOnly
  late final int _foo = 1;
}

class GoodClassStatic {
  @_debugOnly
  static int _foo = 1;
}

class BadClass {
  @_debugOnly
  final int _foo = 1;
}

class BadClass2 {
  @_debugOnly
  late final int _foo;
}

const _debugOnly = Object();
''';

  // ignore: non_constant_identifier_names
  Future<void> test_lazy_initialized() async {
    await assertDiagnostics(source, <ExpectedDiagnostic>[
      lint(145, 33),
      lint(202, 34),
    ]);
  }

Ubernit: is the LHS type necessary? I would assume this is considered to have an obvious type given the collection initialization on the RHS.

Ah interesting, the analyzer is ok with that change but the field above final Map<GlobalKey, Element> _globalKeyRegistry = <GlobalKey, Element>{}; is not omitting obvious types. I looked at the blame and that part was update in April, but it only changed the wording for local types:
0201778, @loic-sharma do you know what the current recommendation is for instance variables?

Ok I think I'll merge this as-is (since existing fields have the full type specified on both lhs and rhs, and the style guide seems to indicate that's the convention). If that recommendation turns out to be outdated we would have to update all existing fields anyway.