undefined_identifier and other errors are no longer ignorable, causing issues for generated parts

[greglittlefield-wf]

As of Dart 2.9.0, the undefined_identifier error is no longer ignorable, along with mixin_of_non_class, undefined_class, undefined_identifier, and invalid_assignment .

This is problematic for the over_react use-case, in which we generate part files via a build-to-cache builder (meaning the files aren't checked in), and reference some generated members in those files from the original file.

For example:

// source file: foo.dart

import 'package:over_react/over_react.dart';

part 'foo.over_react.g.dart';

UiFactory<FooProps> Foo = _$Foo; // ignore: undefined_identifier

...

// generated file: foo.g.dart

part of 'foo.dart';

UiFactory<FooProps> _$Foo = ...; 

...

We use // ignore: undefined_identifier (as well as project-wide ignores of uri_has_not_been_generated) so that the source files can analyze cleanly when the generated file doesn't exist or when the generated file is out of date.

In Dart 2.9.0, these ignore comments no longer work, so over_react projects cannot analyze cleanly without first running a build, which is a pretty big hit to the dev experience in IDEs.

We also have some other deprecated boilerplate code that references generated members in other ways:

class FooProps extends _$FooProps
    with
        // ignore: mixin_of_non_class, undefined_class
        _$FooPropsAccessorsMixin {
  // ignore: undefined_identifier, undefined_class, const_initialized_with_non_constant_value
  static const PropsMeta meta = _$metaForFooProps;
}

We're in the process of migrating off of this pattern and moving toward that single undefined_identifier ignore, but we still have a bit of it in our code bases.

This is also closely related to #42832; if the analyzer knew these APIs were generated and could suppress errors without needing ignore comments, that might help solve this problem. However, we'd still have the issue of warnings in outdated generated files.

[greglittlefield-wf]

I did some more research and found that the issue is that 2.9.0 made it so that errors can no longer be ignored... #27218

[robbecker-wf]

@kevmoo @pq @devoncarew @greglittlefield-wf
Look like @zoechi was right about removing the ability to ignore errors causing problems with generated code (link #27218 (comment))

I'm not sure what our path forward is here. Right now we're blocked from upgrading to 2.9.0. Possible options / workarounds to discuss:

• Allow ignoring errors in generated files 🤔
• Allow downgrading errors to warnings in analysis_options.yaml 😒
• Revert the change of not being able to ignore errors 😬
• We change over_react builders to build to source 😱
• ... something else .. [insert idea here]

Edit: I'll add this isn't a hair on fire emergency .. we can take some time to get the right fix since we don't need to update to 2.9 today or anything like that.

[kevmoo]

CC @natebosch and @jakemac53 –

[devoncarew]

Allow downgrading errors to warnings in analysis_options.yaml

Does this work for you? If you change the severity of undefined_identifier to a warning, does that work - does the analysis server respect the new severity, or does it stay as an error?

https://dart.dev/guides/language/analysis-options#changing-the-severity-of-rules

[natebosch]

so that the source files can analyze cleanly when the generated file doesn't exist or when the generated file is out of date.

How feasible is it to tolerate errors when the generated files are out of date? Just to make sure we're looking at the whole problem - what are the critical places where there is no tolerance for false positives for diagnostics and can we ensure that the generate files are use in those places? Is there something we can do to make it easier to analyze with generated to cache files on c.i. infrastructure?

[robbecker-wf]

@devoncarew Currently it does not work to try to downgrade to non-error. That would require a code change in dart-land. I'm guessing this solution isn't great because it technically opens up a loophole for people to ignore legit errors.

[greglittlefield-wf]

From @robbecker-wf:

... something else .. [insert idea here]

Another potential long-term solution if we can't ignore errors moving forward would be to utilize namespaced imports, which are treated as dynamic accesses when the file has not been generated.

final Foo = generated_lib.Foo as UiFactory<FooProps>;

We'd probably end up still using parts so that we'd be able to access private members of the source file, so we'd have both a generated part and a generated import.

We'd also need casts to get rid of errors, and we'd still have the same problem when the generated file is outdated

So, this probably isn't the best path forward, but I thought I'd throw it out as an option

[greglittlefield-wf]

How feasible is it to tolerate errors when the generated files are out of date?

@natebosch I think it wouldn't be critical for CI, since we could just always regenerate files before we perform analysis.

I think the bigger issue is when developing locally; if a consumer is authoring some code and there's an error resulting from out of date generated code, that could get pretty confusing. This never used to be an issue for this builder, and the generated files use build_to: cache, so it might not be immediately obvious that the solution is to rerun a build.

[jakemac53]

Longest term, this might be a good use case for external. I had worked up a bit of a proposal and even a prototype that allowed external to be used by any library, and then you would generate patch files which have the actual implementation and are read in by kernel.

Is that something that would work for over_react?

As an example of the first type of error you listed:

UiFactory<FooProps> Foo = _$Foo; // ignore: undefined_identifier

would become:

external UiFactory<FooProps> Foo;

This doesn't reference any unknown symbols, and the analyzer is already totally ok with it without any changes. As long as you can describe your generated things in terms of external fields, methods, etc, then I think it actually solves a lot of potential issues.

[aaronlademann-wf]

Forgive my directness, but in reading through #27218 - I don't come away with a clear understanding of what value is added for consumers by not allowing errors to be ignored. Is there some critical roadmap feature that necessitated this change?

To me, this seems like something that should be a build flag - since it is mostly a build-time concern IMO.

[jakemac53]

It doesn't appear like code generation was seriously considered in the original thread as a potential valid use case for ignoring errors, it was brought up briefly but not really discussed.