Draft: Add support for adding constructor

[JCWasmx86]

This adds support for implementing normal constructors (new A()).

Neither named constructors (new A.foo()), nor methods will be possible without either a significant amount of work and/or collaboration with libvala.

For named constructors, it worked once, except I had to call .check explicitly, as otherwise the value_type of each argument would be null. But either a libvala update or a VLS update made this fail.

For methods the same, but even calling check didn't work for me.

Two options for this:

• Make it work in libvala
• Implement a type resolver in VLS (Ugly)

[Prince781]

I think we need to consider how this feature will work and what's in scope now. Some issues:

• What happens if the constructor is already used elsewhere? Should we add a new param if possible? Should we overwrite the constructor's signature? Or should we ignore this case? Also, if we go the route of checking use, we'd have to be careful about performance.
• Generating an async constructor for yield statements.
• Handling constructors that are private.
• Choosing whether to generate a printf-style constructor if we see a pattern like new T("%d %d", 3, 4) (a format-style string as first param). Such a constructor would be:

[PrintfFormat]
public T(string format, ...) {
}

[JCWasmx86]

Agreed.

• Currently you don't get a code action if a constructor is already defined.
• Should be quite doable.
• Handling constructors that are private: What do you mean by this?
• Printf-Style: Would be probably be a bit difficult to detect as we need to parse the string. But if we use some heuristics, it should be somewhat workable. (Think of: If args[0] is a string and args[1] is a string and args[0] contains "%s", we assume a PrintfFormat, just a bit smarter)