build_resolvers error with latest analyzer + next flutter stable

[jakemac53]

The flutter SDK has // @dart=2.9 comments in it, meant to opt it in, but the latest analyzer now requires language version 2.10 (regardless of the current sdk version).

I don't know the best way to resolve this, soon flutter will presumably have the // @dart=2.10 comments (it will have to), but all old flutter sdks would be broken with build_runner if users get the latest analyzer.

cc @scheglov @leafpetersen @natebosch

[jakemac53]

Note that when the next flutter stable lands any time a user runs pub upgrade they will mostly likely hit this issue (assuming they get the latest analyzer).

The only recommendation we can give those users as far as i know is to pin their analyzer version to something older.

[franklinyow]

@franklinyow

[leafpetersen]

Ok, summarizing some discussion.

• The flutter engine web port landed with some // @dart=2.9 comments for opting libraries in. These should be removed (they have been changed to // @dart=2.10 in the current master). cc @yjbanov They should be unnecessary.
• The current flutter stable will go out with a 2.9 sdk, and with those comments listed as // @dart=2.9
• The analyzer package has a wide sdk constraint, and the latest published version claims that it will work with a 2.9 sdk , so it will be picked up by users on flutter stable with dart 2.9 cc @stereotype441 @scheglov @devoncarew
• The latest published version of the analyzer treats // @dart=2.9 as opting code out rather than in

As a result of the above, build_runner users (and any other users who use the analyzer package to analyzer the flutter sdk) will get broken unless they pin to an older version of the analyzer package.

Options to proceed:

• Do nothing. build_runner users will get broken and will need to pin to an older analyzer. cc @kevmoo
• Try to get a cherry pick into flutter stable to remove the //@dart=2.9 comments. This should be a no-op as far as flutter itself is concerned, but it's late (possibly even mechanically too late) in the release cycle for this. cc @pcsosinski
• Publish a new analyzer that supports both 2.9 and 2.10 as an opt in. This doesn't fix the breakage, but it does make pub upgrade work as a solution (and apparently this path to breakage exists independently of language versioning).
• Publish new versions of build_runner with tight sdk constraints that pin the appropriate analyzer? cc @jakemac53 does this work?

[jakemac53]

Another wrinkle I just realized here is all the allow listed packages will also have a problem. They have a 2.9 language version as well (as specified by their sdk constraint) and will not be properly opted in. So just fixing the flutter libraries won't fully resolve the issue, although it will allow us to summarize the SDK properly.

Any imports to package:flutter will have transitive errors in build_runner builds, and any direct imports of allow listed packages will also have errors.

[jakemac53]

Posting here so I don't forget, but I noticed that build_resolvers also relies on the existing experiments spec which says they only work on the current version. We need to remember to remove that check if the behavior changes.

[pcsosinski]

Ok, summarizing some discussion.

• The flutter engine web port landed with some // @dart=2.9 comments for opting libraries in. These should be removed (they have been changed to // @dart=2.10 in the current master). cc @yjbanov They should be unnecessary.
• The current flutter stable will go out with a 2.9 sdk, and with those comments listed as // @dart=2.9
• The analyzer package has a wide sdk constraint, and the latest published version claims that it will work with a 2.9 sdk , so it will be picked up by users on flutter stable with dart 2.9 cc @stereotype441 @scheglov @devoncarew

this seems like a bug. can it be fixed and published?

• The latest published version of the analyzer treats // @dart=2.9 as opting code _out_ rather than in

As a result of the above, build_runner users (and any other users who use the analyzer package to analyzer the flutter sdk) will get broken unless they pin to an older version of the analyzer package.

Options to proceed:

• Do nothing. build_runner users will get broken and will need to pin to an older analyzer. cc @kevmoo
• Try to get a cherry pick into flutter stable to remove the //@dart=2.9 comments. This should be a no-op as far as flutter itself is concerned, but it's late (possibly even mechanically too late) in the release cycle for this. cc @pcsosinski

it would have to be ready to go (tested on branch) by Thursday of this week. but based on @jakemac53's comments below I'm not sure if it's going to solve us.

• Publish a new analyzer that supports both 2.9 and 2.10 as an opt in. This doesn't fix the breakage, but it does make pub upgrade work as a solution (and apparently this path to breakage exists independently of language versioning).
• Publish new versions of build_runner with tight sdk constraints that pin the appropriate analyzer? cc @jakemac53 does this work?

[jakemac53]

this seems like a bug. can it be fixed and published?

We need to think more about how this interacts with the old versions that are published and have wide sdk constraints. Because those do exist the concern is that people end up with really _old_ analyzer versions which puts you in a similar situation.

At least as far as the immediate issue is concerned, it wouldn't help because there is a current published version whose current language version is 2.10 and has a wide constraint, so publishing a new version will just result in users getting the existing one.

We could possibly however do the following, and it might work for more users than not:

• publish a new version 0.39.16 which is identical to 0.39.14, except with an sdk constraint like >=2.9.0-0.0 <2.10.0
• publish a new version 0.39.17 which is identical to 0.39.15, except with an sdk constraint like >=2.10.0-0.0 <2.11.0

This would make it so most users would not get the "bad" 0.39.15 version, pub would instead choose one of the newer versions, at least until 2.11 at which point we would need a new analyzer or else users would get the older 0.39.15 version again.

[devoncarew]

To paraphrase the last solution a bit:

publish a new version 0.39.16 which is identical to 0.39.14, except with an sdk constraint like >=2.9.0-0.0 <2.10.0
publish a new version 0.39.17 which is identical to 0.39.15, except with an sdk constraint like >=2.10.0-0.0 <2.11.0

This helps us because we want people on the 2.9 SDK to be able to use // @dart=2.9 to opt-into NNBD, and people on 2.10 to be able to use // @dart=2.10.

If that's correct, the dual publish of package:analyzer sounds like a reasonable solution (solves the issue, and low-risk for further complications).

edit: thinking about this more, I'd be concerned about how we'd get package:analyzer api changes or fixes to users on dart 2.9; that'll be the stable version for ~3 months

We could publish the experiments flag info as a package, and put sdk constraints (^2.9, ^2.10) on that?

[jakemac53]

We are going to do a temporary fix here to pin the analyzer, longer term we have a plan to change how experiment language versions work, such that they can be pinned to a certain version instead of the "current" version which caused a lot of pain when switching from 2.9 -> 2.10.

[jakemac53]

A new version of build_runner has been published which pins analyzer, so a pub upgrade should fix this issue for most users now.

I am going to leave this open until we implement the long term fix though.

[jakemac53]

Note that this won't necessarily help if you have another transitive dependency on analyzer (like test for instance) which comes first in your pubspec.

I think we should probably additionally work on the two analyzer releases that I described to resolve the issue more thoroughly. We could always expand the constraint later on if so desired.

cc @leafpetersen @scheglov @stereotype441 @devoncarew

[leafpetersen]

I think we should probably additionally work on the two analyzer releases that I described to resolve the issue more thoroughly.

This is fine by me.

[devoncarew]

I think we should probably additionally work on the two analyzer releases that I described to resolve the issue more thoroughly. We could always expand the constraint later on if so desired.

You're suggesting an analyzer which works (solves) for 2.9, and one which works for 2.10? The 2nd one I'd have concerns about - that would mean we wouldn't be able to get changes or fixes to people on 2.9 (the upcoming stable release) going forward.

[jakemac53]

You're suggesting an analyzer which works (solves) for 2.9, and one which works for 2.10? The 2nd one I'd have concerns about - that would mean we wouldn't be able to get changes or fixes to people on 2.9 (the upcoming stable release) going forward.

This would not have to be a long term thing, just temporary releases to resolve this issue. Once the longer term solution is implemented analyzer could widen the constraint later on, if we think that is the right thing to do (spoiler alert I don't haha but that is orthogonal and it isn't my project).

[scheglov]

Do we still need two version of analyzer for 2.9 and 2.10?
Or we can go with the "option 4" in the document, and allow experiments with whatever is the current SDK version?

[leafpetersen]

I'm fine with option 4 given the understanding that the allow list is taken from the end users SDK. That is, if package collection is added to the allow list in Dart 2.9, it is important that when run on a Dart 2.8 SDK, the analyzer package not treat package collection as being in the allow list, since otherwise versions of package collection which were intended to be opted out will be treated as opted in.

[jakemac53]

If we go with option 4 and can implement it relatively quickly, then I would be ok without publishing two new analyzer versions (for 2.9 and 2.10). But some users were already broken, and not all of them will be fixed by the change we made in build_runner to pin analyzer (they may end up getting the previous build_runner version instead of the previous analyzer depending on their pub solve)

[scheglov]

I started working on a CL to access the language version from SDK, but I hit issues that analyzer is given incomplete SDK (no version file). This happens during building SDK summary, benchmarking, some other cases. In these cases the analyzer is given --dart-sdk=sdk, which has all libraries, but not the version file. So, the analyzer cannot know the version of the SDK, and correspondingly of the SDK.

I think it is not reasonable to expect that analyzer works with incomplete SDK.
I asked @whesse if he can help to solve the issue with building, and @sortie to update the benchmark script.

But now it will take some time when, or if, these additional changes will be made by other people.

[Sauraus]

Actually analyzer-0.39.14 doesn't seem to do much better for us

~/github/iOS/vid_flutter_plugin/packages/vid_flutter_core ~/github/iOS/vid_flutter_plugin
Failed to precompile build_runner:build_runner:
../../../../../flutter/.pub-cache/hosted/pub.dartlang.org/build_resolvers-1.3.9/lib/src/resolver.dart:340:10: Error: Method not found: 'SummaryBuilder'.
return SummaryBuilder(sdkSources, sdk.context).build(
^^^^^^^^^^^^^^
../../../../../flutter/.pub-cache/hosted/pub.dartlang.org/build_resolvers-1.3.9/lib/src/resolver.dart:329:7: Error: The setter 'useSummary' isn't defined for the class 'FolderBasedDartSdk'.

• 'FolderBasedDartSdk' is from 'package:analyzer/src/dart/sdk/sdk.dart' ('../../../../../flutter/.pub-cache/hosted/pub.dartlang.org/analyzer-0.39.14/lib/src/dart/sdk/sdk.dart').
  Try correcting the name to the name of an existing setter, or defining a setter or field named 'useSummary'.
  ..useSummary = false
  ^^^^^^^^^^

And we are using build_resolvers 1.3.10 as per https://github.com/dart-lang/build/issues/2764

[jakemac53]

@Sauraus A pub upgrade should resolve your issue (you will need build_resolvers 1.3.10 which you should get on an upgrade)

[cpboyd]

As stated in https://github.com/flutter/flutter/issues/62240#issuecomment-669679228, if pubspec.yaml lists a value other than build_runner: ^1.10.1, it seems that it falls back to 1.10.0 instead of 1.10.1 when 1.10.2 fails.

@jakemac53 Is this intended? Or is it a bug with pubspec resolution?

[jakemac53]

This is likely just a reflection of how the pub solve algorithm works, but not a bug.

Basically, if it starts trying to solve for analyzer versions before solving for build_runner versions this could happen. Either way you won't be getting the latest of one or the other, so it is somewhat arbitrary which it would choose to downgrade.

Re-ordering your dependencies so that build_runner is first in the section could even resolve it. You may have some other dependency earlier which also has an analyzer dependency, causing it to solve for that first.

We do have a larger fix coming soon hopefully which will resolve this from the analyzer side of things.

[jakemac53]

cc @scheglov does the analyzer now read the version from the sdk being analyzed or were you still blocked on that?

[scheglov]

I'm currently blocked on https://dart-review.googlesource.com/c/sdk/+/122483 to make use this language version in the analyzer.

[EskAere]

Hi !

I tried analyzer-0.39.14, i no longer have the version issues, but i now have those issues :

PS C:\Projects\Flutter\build-up\build_up> flutter pub run build_runner clean
Precompiling executable...
Failed to precompile build_runner:build_runner:
/C:/flutter/.pub-cache/hosted/pub.dartlang.org/dart_style-1.3.7/lib/src/source_visitor.dart:1428:21: Error: The getter 'externalKeyword' isn't defined for the class 'FieldDeclaration'.
 - 'FieldDeclaration' is from 'package:analyzer/dart/ast/ast.dart' ('/C:/flutter/.pub-cache/hosted/pub.dartlang.org/analyzer-0.39.14/lib/dart/ast/ast.dart').
Try correcting the name to the name of an existing getter, or defining a getter or field named 'externalKeyword'.
      modifier(node.externalKeyword);
                    ^^^^^^^^^^^^^^^
/C:/flutter/.pub-cache/hosted/pub.dartlang.org/dart_style-1.3.7/lib/src/source_visitor.dart:1430:21: Error: The getter 'abstractKeyword' isn't defined for the class 'FieldDeclaration'.
 - 'FieldDeclaration' is from 'package:analyzer/dart/ast/ast.dart' ('/C:/flutter/.pub-cache/hosted/pub.dartlang.org/analyzer-0.39.14/lib/dart/ast/ast.dart').
Try correcting the name to the name of an existing getter, or defining a getter or field named 'abstractKeyword'.
      modifier(node.abstractKeyword);
                    ^^^^^^^^^^^^^^^
/C:/flutter/.pub-cache/hosted/pub.dartlang.org/dart_style-1.3.7/lib/src/source_visitor.dart:2618:21: Error: The getter 'externalKeyword' isn't defined for the class 'TopLevelVariableDeclaration'.
 - 'TopLevelVariableDeclaration' is from 'package:analyzer/dart/ast/ast.dart' ('/C:/flutter/.pub-cache/hosted/pub.dartlang.org/analyzer-0.39.14/lib/dart/ast/ast.dart').
Try correcting the name to the name of an existing getter, or defining a getter or field named 'externalKeyword'.
      modifier(node.externalKeyword);
                    ^^^^^^^^^^^^^^^
pub finished with exit code 1

[jakemac53]

@EskAere does the latest analyzer work for you now? I think it may resolve the original issues stated here.

Otherwise the latest dart_style requires the latest analyzer so overriding it to an earlier version now results in this error.

You could set your analyzer version via dev_dependencies or dependencies instead of dependency_overrides which should resolve it (that will end up giving you an older dart_style). Or you could pin an older dart_style :/.

[EskAere]

Yes i confirm, it's working for me with latest analyzer now ! Thank you !

[jakemac53]

Ok, I am going to close this issue as I believe the root cause is in fact resolved now, please try removing your dependency overrides, upgrading to the latest analyzer, and confirming it fixes things (if you haven't already).

If it doesn't please respond here with the issues you are still encountering.

[amanv8060]

It is still not working

dependencies:
  flutter:
    sdk: flutter
  firebase_core: ^0.4.5
  firebase_analytics: ^5.0.16
  firebase_auth: ^0.16.1
  cloud_firestore: ^0.13.7
  google_sign_in: ^4.5.1
  cupertino_icons: ^0.1.3
  cached_network_image: ^2.2.0+1
  image_picker: ^0.6.7+4
  adobe_xd: 1.0.0+1
  flutter_svg: 0.17.4
  hive: ^1.4.2
  hive_flutter: ^0.3.1
  hive_generator: ^0.7.1

dev_dependencies:
  flutter_test:
    sdk: flutter
  build_runner: ^1.10.2

# dependency_overrides:
#   analyzer: 0.39.14

flutter:
  uses-material-design: true
  assets:
  - assets/

also the error is

Because project_name depends on build_runner >=1.10.2 which requires SDK version >=2.10.0-0.0 <3.0.0, version solving failed.
pub get failed (1; Because project_name depends on build_runner >=1.10.2 which requires SDK version >=2.10.0-0.0 <3.0.0, version solving failed.)
exit code 1

earlier overriding did work , but now that also doesnt work

[jakemac53]

@amanv8060 you need to have a wider constraint on build_runner (^1.10.0 maybe?) - the latest version requires the dev sdk.

[amanv8060]

i don't know what was wrong ,at last i was able to get the desired thing , deleted my old project , created a new project , then copied the old pubspec in new one and it worked .

both did not have dependency override ..

We can lock this now , i guess

[amitkhairnar44]

i don't know what was wrong ,at last i was able to get the desired thing , deleted my old project , created a new project , then copied the old pubspec in new one and it worked .

both did not have dependency override ..

We can lock this now , i guess

It didn't work before because some dependencies were locked to a fixed version in pubspec.lock.

The easy fix is to delete the pubspec.lock file and run pub get command, which will generate new pubspec.lock file.