[record_use] Completeness: non-const Constructors calls

[dcharkes]

constructor calls (non-constant invocations; like treating the constructor also as a static method and collecting the provided constant parameters)

#2902

Some things to solve over normal static calls:

• What to do with super-calls to such constructors? Are they considered invocations with all dynamic arguments? The compilers don't necessarily inline the constructors and their arguments.
• What to do with const constructors? [record_use] Correctness: Scope const instance recording to annotations only #2719 proposes to stop recording const instances that are not in an annotation position.

@schultek Could you please provide some code snippets of your wished use cases 🙏

[schultek]

I would like to do something like this:

class Column {

  @RecordUse
  @MyOwnAnnotation
  const Column({this.spacing = 0});

  ...
}

... build() {
  return Column(spacing: 42);
}

And then have this call recorded with the const parameters.

What to do with const constructors? [record_use] Correctness: Scope const instance recording to annotations only #2719 proposes to stop recording const instances that are not in an annotation position.

I don't care about const instances of Column in this case. And for the call recording it shouldn't be a difference whether the call site uses const or not.

What to do with super-calls to such constructors? Are they considered invocations with all dynamic arguments? The compilers don't necessarily inline the constructors and their arguments.

It could be cool if super calls also trigger a recording of the superclass constructor, but it's not something I would need really as widgets shouldn't be subclassed anyways.

[dcharkes]

And for the call recording it shouldn't be a difference whether the call site uses const or not.

It makes a big difference unfortunately in the compiler! 😄

1. The early compiler phase we might still see it as a constructor call, but then we haven't done any dead code elimination and other optimizations.
2. Then it is immediately converted to a const instance in the constant pool and the constructor call in the source code is replaced with a reference to that const instance. The information of which constructor was used is lost.

So in order to support such logic, we would need to annotate the const-reference in the ast with what constructor was called. And then if such consts are propagated and used in other consts "migrate" such annotation to the new use sites so that once all optimizations are done we can still get a clear picture of which constructors were "called". This would be a significant undertaking to implement in the VM, dart2js and dart2wasm. (Hence why I filed this issue to stop recording const instances in executable Dart code and only allow const instances in annotation positions where there is 0 ambiguity whether it's a static call or a const instance.)

TLDR: We might be able to support this. But it will require significant work.

Originally posted by @dcharkes in #2719

[schultek]

I see. So does that mean we can record non.const calls for constructors though.
I can probably work around the const calls by inspecting the const instances, but then these would need to be recorded for non-annotation usages.

[dcharkes]

I can probably work around the const calls by inspecting the const instances, but then these would need to be recorded for non-annotation usages.

Yeah, but that's rather messy. So then I'd rather do all the significant compiler work so that const and non const invocations of const constructors are reported in a uniform way.

Adding support for non const constructors should be easy indeed. And then we need to error on a @RecordUse() on a const constructor. Let's split that out into two separate tracking bugs one for non-const constructors and one for also supporting const-constructors.