Analyzer should reject prefix shadowed by parameter

[stereotype441]

Consider the following code:

import 'dart:async' as a;

g(int x) async => x;
f(int a) {
  a.Future<int> x = g(a);
  return x;
}
main() async {
  print(await f(0));
}

The front end rejects this code with the following error:

../../tmp/test.dart:5:3: Error: 'a.Future' can't be used as a type because 'a' doesn't refer to an import prefix.
  a.Future<int> x = g(a);
  ^^^^^^^^

The analyzer accepts it, offering only this hint:

  hint • Unused import: 'dart:async'. • /usr/local/google/home/paulberry/tmp/test.dart:1:8 • unused_import

It seems that for type analysis, the analyzer is considering the a in a.Future to refer to the import of dart:async, but for determining whether the import is used, it's considering it to refer to the a parameter of f.

The spec seems pretty clearly in agreement with the front end. In the section "Static Types", it says:

A type T is malformed iff:

• T has the form id or the form prefix.id, and in the enclosing lexical scope, the name id (respectively prefix.id) does not denote a type.

Note that although the example above is contrived, this bug did arise in a real-world circumstance for me; I was attempting to write a method taking an argument called path, in a file that contained import 'package:path/path.dart' as path, and inside that method I attempted to declare a variable of type path.Context. The analyzer did not flag an error (nor did I realize my own mistake); I didn't see an error until I tried to run the program.

[bwilkerson]

@eernstg Will this continue to be the semantics after the spec changes related to prefixes that you mentioned recently in a different context?

[eernstg]

Yes, there are no plans to change the lexical lookup rules. So when a denotes a formal parameter of type int in the body of f according to the scope rules, a.Future.... is an attempt to access a member named Future on the value of that parameter. The import prefix named a is shadowed by the parameter and hence it is never the result of a lexical lookup in this scope. So a "prefix object" is not a Dart object, but lookups of the form id1.id2 do follow the normal scope rules also when id1 denotes a prefix object.

[scheglov]

See also #42493, which also would fix the issue.

[stereotype441]

Turning over to Konstantin to improve on my hacky fix

[scheglov]

Reporting CompileTimeErrorCode.PREFIX_SHADOWED_BY_LOCAL_DECLARATION was moved into TypeNameResolver in 86ec742.