dartanalyzer: 'Evaluation of this constant expression throws an exception' when creating a simple rectangle

[denniskaselow]

Not really a bug but a change in behavior, and the fix is easy in a project running into this but finding the reason takes some time as it's not obvious, so this is more of a FYI for people running into the same bug. I am on Dart SDK version: 2.10.0-110.0.dev (dev) (Wed Sep 9 17:51:43 2020 -0700) on "windows_x64" and I'm not sure when it started appearing.

The dartanalyzer will error on this code

import 'dart:math';

void main() {
  const rectangle = Rectangle(0, 0, 100, 100);
  print(rectangle);
}

If the sdk in pubspec.yaml has a lower limit below 2.5, like sdk: '>=2.4.0 <3.0.0' then this error will be reported:

Analyzing constbug...
  error - Evaluation of this constant expression throws an exception. - bin\constbug.dart:4:21 - const_eval_throws_exception
1 error found.

With a lower sdk limit of at least 2.5.0 this won't be reported as an error any longer.

Maybe because 2.5.0 introduced new allowed operations in constant expressions, like

Casts (e as T) and type tests (e is T).

And Rectangle recently (in june) got such a change (but using dynamic instead of T).

[lrhn]

Interesting. Sounds like an analyzer error.
Using SDK >= 2.4.0 will set your language version to 2.4 for your own code, which should be equivalent to 2.7 because language versioning does not go further back than its own introduction. That should not affect the SDK code.

[bwilkerson]

@scheglov

[scheglov]

It seems to me that there are two issues.

1. Features that were introduced before 2.5 should be considered to be declared in 2.0. As stated in Should language versioning require opting in to non-breaking changes? language#286 (comment).

2. @lrhn said that the language version "should not affect the SDK code", which probably means that in general case constant expressions should evaluated with the feature sets of the enclosing library, not with the feature set of the library that initiated evaluation.

@lrhn @eernstg @leafpetersen does this sound right to you?

[eernstg]

I would expect every term t that occurs in a library with language version V to be treated as having language version V, and it does not matter that (some number of steps earlier during analysis/compilation/execution) the reason for processing t involves some other library with a different language version.

[leafpetersen]

@scheglov That seems like a nice behavior if we can achieve it.

[scheglov]

Both (1) and (2) from #43462 (comment) were done.