My understanding of the specification is as follows.

The function 'f' is defined in the library scope and hence is visible on line 4 ("f();") where it is invoked.

The formal parameter scope (nested in the library scope) defines the name 'f'. This is analogous to a local variable, which means that the name of the parameter cannot be used in the default value expression, but could be used by parameters following 'f' (if there were any, which in this case there are not).

Changing this to a language issue for clarification, both of my interpretation of the specification and whether that's how we want the specification to read.

cc @gbracha.
Removed Area-Analyzer label.
Added Area-Language label.

The spec says that the scope of a function's signature is the function's enclosing scope, so in this case, the default value is the top level function f. It is therefore impossible for a parameters default to refer to itself, and the analogy to locals is unfounded.

I'm passing this to the analyzer team to check if they need this is still an issue or give any other feedback.

Removed Area-Language label.
Added Area-Analyzer label.

Removed Priority-Unassigned label.
Added Priority-Medium label.

Added this to the 1.10 milestone.
Removed Priority-Medium label.
Added Priority-High label.

Set owner to @stereotype441.
Added Started label.

This is a bug in analyzer having to do specifically with function-typed formal parameters. Note that the code snippet is analyzed correctly if you change the type of the function parameter to "dynamic":

void f([dynamic f = f]) { print("?");if (f != null) f(null); }

main() {
  f();
  print("ok");
}

Fix is out for review: https://codereview.chromium.org/978633003/

Fixed in revision 44212.

Added Fixed label.