Analyzer is of two minds regarding a property/super-parameter accessed as the prefix of a method call target.

[srawlins]

There are a few requirements to triggering this, which explains why it still exists on stable branch (and all the way up to main branch):

class C {
  late int f;
  C({int? f}) {
    this.f = f ?? 7;
  }
}

class D extends C {
  D({super.f}) {
    f .isEven.toString();
  }
}

• Given this code, there is a compile-time error at f.isEven claiming that f could be null.
• If you change the statement to start as f?.isEven or f!.isEven, then there are warnings that f cannot be null.

Code requirements:

• super class has field f.
• subclass has nullable super formal parameter, f.
• property is called on f (.isEven) in ctor body, and a method (.toString()) is called on the property.

A hint: when you Go-to-definition of f in the original code, you are taken to super.f. When you Go-to-definition at f? or f!, you are taken to the super field.

[jakemac53]

See here, Like we currently allow this.id as an initializing formal in a non-redirecting generative constructor, with an implicit type derived from the id variable declaration, and introducing a final variable in the initializer list scope, we will also allow super.id. - the parameter should only be in scope in the initializer list and not the body.

So, f in the body should be referring to the late int f field on C. It appears that in one case here (the diagnostic saying f could be null), it is actually looking at the super parameter f and not the field f.

See also the text Introduces a final variable p with the parameter’s name, just like this.p does, only in scope in the initializer list. here.