[cfe] `ConstantExpression.getStaticType()` returns `DynamicType` despite the constant having more precise type

[mkustermann]

Backends often use expr.getStaticType() to get the static type of an expression.

The ConstantExpression implements this by just returning ConstantExpression.type which is often Dynamic as that's the default value. Though instead of this it could rather make it more precise via

@@ -4650,7 +4650,10 @@ class ConstantExpression extends Expression {
       getStaticTypeInternal(context);

   @override
-  DartType getStaticTypeInternal(StaticTypeContext context) => type;
+  DartType getStaticTypeInternal(StaticTypeContext context) => constant.getType(context);

   @override
   R accept<R>(ExpressionVisitor<R> v) => v.visitConstantExpression(this);

This would avoid backends having to workaround this issue and special casing ConstantExpression specially.

[mkustermann]

/cc @johnniwinther

[lrhn]

The static type of a constant should be what the type inference infers for it, just like any other expression. If it isn't, then that does sound like a bug.

The static type is not necessarily the runtime type of the value (although it likely is, if no casts or LUBs are involved).

If I do const c = 42 as dynamic;, then the static type of the constant expression c should be dynamic.

[mkustermann]

I've observed for example in some code that does identical(foo, null) the null is a ConstantExpression with a DynamicType as type and a NullConstant as constant.

This may also be due to various modular or global kernel transformers inserting ConstantExpression(constant) forgetting that the constructor looks like this

class ConstantExpression extends Expression {
  Constant constant;
  DartType type;

  ConstantExpression(this.constant, [this.type = const DynamicType()]);
  ...
}

i.e. defaults to DynamicType.

[mkustermann]

From a backend perspective, we have an Expression and would like to get the most precise type for that expression. If such expression is a ConstantExpression then the most precise type for this expression is expression.constant.getType() and not DynamicType.

For now I'll just special case this in the backend.

[lrhn]

That does make sense. In the backend, you're not doing type inference, you just need to see what you can definitely know about the value, and what you might need to check for. Like, if the static type is dynamic and there is an implicit downcast to int, knowing that the value is definitely an int means you can elide the downcast.
A "best known type" would be fine for that, precisely if it's not the static type.

[johnniwinther]

cc @chloestefantsova