update `prefer_const_declarations` for constructor tear-offs

[pq]

prefer_const_declarations

@srawlins: I think you added this one to the list. Could you elaborate on the support / test cases you had in mind?

/fyi @bwilkerson

[srawlins]

Given:

class C {
  const C();
}

I wonder if we want to encourage people to write const f = C.new over final f = C.new.

[bwilkerson]

It's my understanding that tear-offs or top-level functions, static methods, and constructors are constant expressions (as long as all the type arguments are constant types). So, yes, that would be consistent with the way the the lint currently works.

[pq]

/cc @lrhn

[lrhn]

It should be covered automatically by the existing lint, if the lint expects you to declare final variables with constant value initializers as expressions as const instead.
A constructor tear-off is (almost always) a constant value, just like a static method tear-off.

So check that:

class C<T> {
  C();
}

void myTest<T>() {   // To introduce a non-constant type.
  final c1 = C.new; // lint!
  final c2 = C<int>.new; // lint!
  final C<int> Function() c3 = C.new; // lint!
  final c4 = C<T>.new; // NO lint, not constant
  final C<T> Function() c5 = C.new; // NO lint, not constant
}

You should have similar tests for static methods:

class C<T> {
   static C<X> m<X>() => C<X>();
}
void myTest<T>() {   // To introduce a non-constant type.
  final c1 = C.m; // lint!
  final c2 = C.m<int>; // lint! (Only with constructor tear-offs features enabled)
  final C<int> Function() c3 = C.m; // lint!
  final c4 = C.m<T>; // NO lint, not constant (only with ....)
  final C<T> Function() c5 = C.m; // NO lint, not constant
}

It's the same thing entirely, and all that matters (as I understand the lint) is whether the expression is constant.
Just need to test that those constant tear-offs are recognized as constant.

[pq]

Thanks for the rationale and added test cases @lrhn!