[WSL] Synthesize constructors for structs

[Myles C. Maxfield]

This will let you put pointers inside structs.

[Myles C. Maxfield]

Object literals are a little tricky because of something like this:

struct Foo {
    int x;
}

struct Bar {
    uint x;
}

void func(Foo f) { ... }
void func(Bar f) { ... }

func({3});

This is a case where the contents of the object literal will participate in function overload resolution.

However, if the goal is simply to be able to specify the contents of a struct in a variable initializer, we don't actually need object literals; we can just synthesize a constructor for each struct which contains members for each field. This means that the author will have to state which type they are constructing, which means that the contents are not considered when performing function overload resolution (and function overload resolution is unchanged.

For arrays, you can't put a pointer or an array reference anywhere into an array, which means that variable initializers are no more powerful than regular assignments; therefore, we don't really need array literals.

Retitling.

[Myles C. Maxfield]

We already synthesize field accesses to structs; adding synthesized constructors shouldn't be too difficult.

[Myles C. Maxfield]

Created attachment 325264 [details]
Patch

[Myles C. Maxfield]

Created attachment 325267 [details]
Patch

[Filip Pizlo]

Comment on attachment 325267 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=325267&action=review

> Tools/ChangeLog:12
> +        Similar to how we synthesize field accesses, we can also synthesize constructors
> +        which initialize each member of the struct. This is more powerful than making
> +        the author write these constructors, because, in logical mode, the native
> +        implementation can assign to pointer fields in the struct, which the author can't
> +        do.

I think that the more canonically-C++-like way to solve this problem is to just add support for struct/array literals.

Like the NullLiteral and the GenericLiteral (that creates IntLiteral and friends), this will have a corresponding type variable, which will only unify with either arrays or structs.

You might as well make this sensible from day one.  For example, {1, 2, 3} should unify with either T[3] where T unified with 1, 2, and 3; or a struct with three fields, whose types (T, U, and V) unify with the values (1, 2, 3).  But {f = 4, g = 6} should only unify with structs that have exactly "f" and "g" as their fields (in any order), and their types unify with 4, 6.

[Myles C. Maxfield]

Migrated to https://github.com/gpuweb/WHLSL/issues/163