Bug 178978 - [WSL] Synthesize constructors for structs
Summary: [WSL] Synthesize constructors for structs
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGPU (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Myles C. Maxfield
Depends on:
Blocks: 176199
  Show dependency treegraph
Reported: 2017-10-27 22:08 PDT by Myles C. Maxfield
Modified: 2018-10-13 19:17 PDT (History)
3 users (show)

See Also:

Patch (11.57 KB, patch)
2017-10-28 11:36 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
Patch (16.65 KB, patch)
2017-10-28 15:04 PDT, Myles C. Maxfield
mmaxfield: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Myles C. Maxfield 2017-10-27 22:08:31 PDT
This will let you put pointers inside structs.
Comment 1 Myles C. Maxfield 2017-10-28 08:55:09 PDT
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) { ... }


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.

Comment 2 Myles C. Maxfield 2017-10-28 08:58:50 PDT
We already synthesize field accesses to structs; adding synthesized constructors shouldn't be too difficult.
Comment 3 Myles C. Maxfield 2017-10-28 11:36:34 PDT
Created attachment 325264 [details]
Comment 4 Myles C. Maxfield 2017-10-28 15:04:28 PDT
Created attachment 325267 [details]
Comment 5 Filip Pizlo 2017-10-30 13:56:59 PDT
Comment on attachment 325267 [details]

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.
Comment 6 Myles C. Maxfield 2018-10-13 19:17:40 PDT
Migrated to https://github.com/gpuweb/WHLSL/issues/163