Set analyzer constraints more conservatively.

[srawlins]

Right now we ship the analyzer package with caret constraints on the Dart SDK, e.g. ^3.9.0. One might interpret this to mean, "I will work with the Dart SDK 3.9.0, and 3.10.0, and 3.11.0, etc." That's normally a fair assumption, with semantic versioning.

But we don't really use semantic versioning in the Dart SDK. 3.10.0 might introduce a new syntax, like dot-shorthands. And code in the Dart SDK 3.10.0 might use that new syntax. For example, this CL. Now the analyzer package which has SDK constraint ^3.9.0 is expected to parse that new syntax (or... kernel or analyzer summary format for that syntax?).

Should we set analyzer constraints on the SDK more conservatively, like >=3.9.0 <3.10.0?

[bwilkerson]

Or should the constraints the analyzer package has on the SDK be independent of the version of the SDK that the package is capable of analyzing?

[srawlins]

Or should the constraints the analyzer package has on the SDK be independent of the version of the SDK that the package is capable of analyzing?

I think that's the situation today, right? AFAIK we don't take "the version of the SDK that the package is capable of analyzing" into account when setting/updating the constraint on the SDK. Which makes the above problem possible.

[scheglov]

Usually it is opposite, we work on a new language feature for the language version X and keep analyzer SDK requirement Y, where Y < X. When it is ready, we pull the analyzer SDK requirement to X.

Theoretically if the language version of the code under analysis is greater than you understand, you just throw an exception?
This is for the analyzer, or for any other package that handles Dart code.

Or the analyzer restricts the language version to the maximum it understands, but this has risks. Usually it will lead to parse errors or semantic errors. But could also cause silent semantics changes. Or report a compile-time error in every library that has too high language version.

[srawlins]

Theoretically if the language version of the code under analysis is greater than you understand, you just throw an exception?
This is for the analyzer, or for any other package that handles Dart code.

Not just theoretically, but in practice as well! This is what is causing the broken flutter roll. analyzer 7.7.1 is being used to analyze Dart 3.11-dev SDK code, and it throws when it encounters dot-shorthands (in dart:developer sources).

Feel free to close if the model team is not going to take this policy. It is just an idea to prevent crashes like that which is blocking the Flutter roll in flutter/flutter#177651.

[lrhn]

It's tricky.

There SDK constraint of the package is which SDK version is needed to run the code.
The current versioning is correct for that.

If the analyzer package depends not just on the runtime semantics of the SDK, but also on the platform library source code, then that's a different kind of constraint.
Normal packages don't take platform library source code as input.

That's what it is: input to the analysis, just like the source code being analyzed.

I assume you could technically run the 3.9-understanding analyzer package on a 3.10 SDK, direct it to the 3.9 SDK sources, and then it should work.

That is not a "which SDK can I run on" constraint, it's a second constraint on the input, one which cannot be expressed in the type system.

The change in which SDK sources are accepted as input is non-breaking when it just allows more language features, so a minor version increment is correct versioning.

[brianquinlan]

I think that having tight SDK constraints in the analyzer is a pragmatic approach. When we are sure that next Dart release will not introduce features that break the analyzer, then the analyzer should release a patch version that includes that release.

This will cause the user to get crisp version solving failure if the are using an outdated analyzer version, rather than a cryptic message like: "Error: Exception: Missing implementation of visitDotShorthandPropertyAccess"
(see https://github.com/dart-lang/http/actions/runs/19046459643/job/54395788206#step:13:153)