Analyzer regression around diagnostics when imported files are not generated

[bwilkerson]

The analyzer used to notice when an import, export or part directive referenced a generate file that does not exist and silenced follow-on diagnostics. That behavior appears to have been broken. For example, a file containing the following:

import 'doesNotExist.g.dart';

void f(A a) {
  var b = A.b;
}

Now produces 3 diagnostics when it ought to produce a single "generated file does not exist" diagnostic.

This has serious implications for internal users.

[bwilkerson]

@scheglov

[scheglov]

Can you point me at a document that specifies the required behavior?

What I see implemented, and what I vaguely remember hearing when this feature was discussed, is that we ignore errors reported on identifiers that are either (1) imported with a prefix; (2) imported without a prefix but with an explicit show combinator. In both cases the library must be synthetic. meaning that its file is missing.

The example provided in the first comment does not satisfy these conditions, so we report multiple errors.
But for the variants we report only one.

import 'doesNotExist.g.dart' show A;

void f(A a) {
  A.b;
}

or

import 'doesNotExist.g.dart' as p;

void f(p.A a) {
  p.A.b;
}

In both cases we get CompileTimeErrorCode.URI_HAS_NOT_BEEN_GENERATED [7, 21, Target of URI hasn't been generated: 'doesNotExist.g.dart'.].

We have a disjoined check for reporting a special error for a missing file when it looks like it might be generated.
But I don't remember changes there, it has always been private, since it was added in 2017.

[bwilkerson]

Can you point me at a document that specifies the required behavior?

Unfortunately, no. I don't believe that we documented the desired behavior.

... we ignore errors reported on identifiers that are either (1) imported with a prefix; (2) imported without a prefix but with an explicit show combinator.

I don't remember those restrictions, but it's quite possible that we decided to do that in order to reduce the number of false negatives.

If that's the case, there is no regression. But I think we should consider broadening the support because using show combinators and prefixes won't work with part directives, which are what's used with most of the code generators. I suspect that users would even be happy having this loosening apply only to part directives at this point.

[scheglov]

OK, then this is not a bug, but an enhancement.

Without additional information we cannot distinguish an identifier that should come from an imported library, and identifier that should come from a part. But I can imagine that there might be a correspondence between a generated part name, and the pattern of names of generated entities in the part.

Do you have examples of such parts and generated identifiers?
Maybe google3 targets which I could look at?

[bwilkerson]

@jwren

[greglittlefield-wf]

Related: #42977 (see note at the bottom of the issue)

---

Do you have examples of such parts and generated identifiers?

I have some examples here for over_react, if they're worth considering 🙂:

• Source file: example/builder/src/basic.dart
• Generated file: example/builder/src/basic.dart.over_react.g.dart

(There are other examples under example/builder/src) as well.

(Note that in this repo the generated files use a build-to-source builder and are checked in, but all consumer repos use build-to-cache.)

To summarize:

• All of our generated members have names that start with either $ or a series of _ and $
• Names in the generated file are derived from prefixing and/or postfixing names in the source file, but a single source member may result in multiple generated members
  • For example: BasicProps results in $BasicProps, _$BasicProps, _$$BasicProps$PlainMap, etc. being generated
  • However, we only support referencing a few of those members in the source file

[devoncarew]

Hey @greglittlefield-wf - to follow up on your last comment (and, cc'ing in @robbecker-wf):

We're looking at expanding the file name patterns for what we consider probably generated code, and, how we then identify the following undefined symbols in that file, to know which missing symbol errors to ignore.

We currently support two patterns for this - import 'doesNotExist.g.dart' show A; and import 'doesNotExist.g.dart' as p;. The nice things about these imports is that they encode the information in them to let us know which errors to suppress (the shown symbols or the ones referenced by the given prefix).

For the imports of the form part 'part_name.g.dart';, we don't have an easy way to know which following errors to suppress.

One possible solution to this would be to use part 'part_name.g.dart'; to identify probably generated code, and _$GeneratedSymbol to then suppress following issues. From @kevmoo, this matches the codegen pattern used by several libraries. Would this generally work for your use case? Note that this would catch _$$Symbol names but not $Symbol names.

One follow-on concern we have here is that this could unintentionally catch user code which is not using codegen.