"type 'Null' is not a subtype of type 'InterfaceElement' in type cast" during code generation about drift HOT 8 OPEN

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.

from drift.

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.

from drift.

Same here.

from drift.

@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 🙃

from drift.

@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).

from drift.

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.

from drift.

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.

from drift.

@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.

from drift.