"type 'Null' is not a subtype of type 'InterfaceElement' in type cast" during code generation

[btrautmann]

Describe the bug

I'm seeing the following error just about every time I run build_runner locally. It can be cleared up with a flutter clean. I can try and take a peek into drift_dev later to see if it's something I can open a PR for, but wanted to open the issue in the meantime.

type 'Null' is not a subtype of type 'InterfaceElement' in type cast
package:drift_dev/src/analysis/resolver/dart/helper.dart 66:41   new KnownDriftTypes._fromLibrary
package:drift_dev/src/analysis/resolver/dart/helper.dart 104:28  KnownDriftTypes.resolve
package:drift_dev/src/analysis/driver/driver.dart 94:28          DriftAnalysisDriver.loadKnownTypes
package:drift_dev/src/analysis/resolver/discover.dart 77:46      DiscoverStep.discover
package:drift_dev/src/analysis/driver/driver.dart 130:7          DriftAnalysisDriver.discoverIfNecessary
package:drift_dev/src/backends/build/analyzer.dart 97:5          DriftAnalyzer.build

Drift version

  drift:
    dependency: "direct main"
    description:
      name: drift
      sha256: b50a8342c6ddf05be53bda1d246404cbad101b64dc73e8d6d1ac1090d119b4e2
      url: "https://pub.dev"
    source: hosted
    version: "2.15.0"
  drift_dev:
    dependency: "direct dev"
    description:
      name: drift_dev
      sha256: c037d9431b6f8dc633652b1469e5f53aaec6e4eb405ed29dd232fa888ef10d88
      url: "https://pub.dev"
    source: hosted
    version: "2.15.0"

Flutter Version

Flutter 3.16.4 • channel stable • https://github.com/flutter/flutter.git
Framework • revision 2e9cb0aa71 (8 weeks ago) • 2023-12-11 14:35:13 -0700
Engine • revision 54a7145303
Tools • Dart 3.2.3 • DevTools 2.28.4

FWIW, I'm using json_serializable and copy_with_extension builders as well.

[simolus3]

It's worrying that this happens a lot, but seemingly not all the time? Looking at the stack trace, this happens when the builder is trying to resolve some classes from package:drift to later check whether the classes you've annotated are subtypes of those. These classes all exist, so it shouldn't fail and especially it shouldn't fail inconsistently. It doesn't even fail on the first type, making it look like the analyzer is kind of in a weird state when this happens.

If you're willing to take a look at drift_dev here and run the build with a local checkout, it would be interesting to see what exportNamespace.definedNames.keys contains in _fromLibrary.

[drriguz]

Same here.

[ivanhercaz]

Same here with the next versions:

• Flutter 3.19.1 • channel stable • https://github.com/flutter/flutter.git
• Framework • revision abb292a07e (hace 5 semanas) • 2024-02-20 14:35:05 -0800
• Engine • revision 04817c99c9
• Tools • Dart 3.3.0 • DevTools 2.31.1
• Drift 2.16.0.

I could "solve" it cleaning the cache and the generated files using dart run build_runner clean, then dart run build_runner watch and it asks me:

[INFO] Found 29 declared outputs which already exist on disk. This is likely because the`.dart_tool/build` folder was deleted, or you are submitting generated files to your source repository.
Delete these files?
1 - Delete
2 - Cancel build
3 - List conflicts

I choose 1, then the problem seems it is solved.

[btrautmann]

@ivanhercaz do you have other Builders being used in your codebase? I had this start happening again consistently and it was occurring any time I modified code that impacted json_serializables inputs. I just didn't have the time at the moment to triage further. But if I get a sec I can do what @simolus3 suggested above and run a local version of drift_dev. Just curious if there's a pattern here before I dive into that.

[ivanhercaz]

@ivanhercaz do you have other Builders being used in your codebase?

Yes, I have one for Riverpod (riverpod_generator 2.3.10) and one for Freezed (freezed_annotation 2.4.1).

[btrautmann]

@simolus3 I was able to get to this and checked out drift locally. To reproduce, I did the following:

• Modified _fromLibrary to contain the following lines:

    final exportNamespace = helper.exportNamespace;
    final invoke = Random().nextInt(1000);
    for (final key in exportNamespace.definedNames.keys) {
      print('BRANDON: $invoke|$key');
    }

• Modified a file that impacted copy_with_extension_gens Builder and then ran dart run build_runner build -v within my own project.

This printed the following in console:

[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|Uint8List
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|TypeConverter
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|JsonTypeConverter2
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|DriftAny
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|UserDefinedSqlType
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|DriftDatabase
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|DriftAccessor
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|Table
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|View
[WARNING] drift_dev on lib/ynab_api/_category.dart:
BRANDON: 263|TableIndex
[SEVERE] drift_dev on lib/ynab_api/_category.dart:

From what I can tell, the missing key is TableInfo. The library being read at the time was drift_dev_helper (determined by printing the Uri being passed to readDart from resolve) which pretty clearly exports TableInfo, so I'm not sure why that wouldn't appear in the exported namespace.

I hope this helps; that may be as far as I can take it without additional breadcrumbs 🙃

[btrautmann]

OK scratch that. I had a hunch that since it was exported, it just wasn't being resolved for some reason, so I swapped out the current implementation of readDart in the AnalysisContextBackend with the following (Essentially just swapping getLibraryByUri for getResolvedLibrary and checking the correct return type):

@override
Future<LibraryElement> readDart(Uri uri) async {
  final result = await context.currentSession.getResolvedLibrary(uri.path);
  if (result is ResolvedLibraryResult) {
    return result.element;
  }

  throw NotALibraryException(uri);
}

With that done, I'm unable to reproduce with the steps indicated above. I'll admit that despite having done some code gen myself, I still struggle with understanding the full implications of the difference between resolving the element model versus the AST, both from a performance perspective but also from an actual functionality perspective, so I can't be confident that there's no downstream impacts of this change, but I at least wanted to point out that it seems to work as intended.

[PROGrand]

final result = await context.currentSession.getResolvedLibrary(uri.path);
  if (result is ResolvedLibraryResult) {
    return result.element;
  }

  throw NotALibraryException(uri);

Actually only works for first time. Second run generates same error. Problem in cache. Only cleaning of .dart_tool and rebuilding resolves this error.