dart-lang / dart-lang/source_gen

Guidance on how to compare Dart types from independent libraries?

Open
#740 9 comments 1 reaction 0 assignees View on GitHub
Dominant language
Dart
Stars
494
Forks
115
Avg merge
12h 13m
Merged PRs (30d)
3

Description

I have a builder that needs to know how types in its input relate to some known static types. For this, it currently runs two analysis steps:

1. `resolver.libraryFor('package:drift/src/drift_dev_helper.dart')`: This library exports all the base types that my builder cares about.
2. `resolver.libraryFor(buildStep.inputId)`: To resolve the element model for the input. `inputId` does not transitively import the helper library from step 1.

Then, I use `TypeChecker.fromStatic` with the types I've received in step in 1 to check whether classes resolved in step 2 are subtypes.
This used to work quite well, but it got broken after upgrading to analyzer 7.0. Even for classes that are subtypes, the type checker sometimes reports no subtype relationship.

After some debugging, I've determined a likely root cause: The analysis session from steps 1 and 2 are different, so all the element models aren't equal as far as the analyzer is concerned. It makes sense that they might be different, because each `libraryFor` call might cause the analysis driver to discover new libraries that would make it start a new session.

In my builder, I really need an API that would be able to resolve multiple independent Dart libraries under a single coherent element model.
I've tried repeating step 1 again in the end in the hope that it wouldn't refresh the session another time, but I didn't have any luck with that.

As far as I know, there currently isn't an analyzer API that could surface unified information about multiple libraries safely. So I'm wondering if there should be one? Or am I doing something wrong here? Does anyone have suggestions for a better workaround?

Contributor guide

Open the contributing guide

Research direction

Start with the two resolver.libraryFor calls described in the issue and the TypeChecker.fromStatic subtype checks, reproducing the behavior after upgrading to analyzer 7.0. Compare the independent library element models and determine whether a safe unified-library API or a documented workaround is needed; done requires an agreed resolution and verified subtype checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
dart
Domain
build-system
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.