Bad error message with underconstrained-implicit-instantiation and function overload about flow

[panagosg7]

FWIW, you get a better error message if you pass in the --show-all-branches flag in the CLI.

Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈ file.js:35:3

Cannot call c.query because: [incompatible-call]
 • Either R [1] is underconstrained by call of method query [2]. Either add explicit type arguments or cast the
   expression to your expected type.
 • Or string [3], a primitive, cannot be used as a subtype of Submittable [4]. You can wrap it in new String(...)) to
   turn it into an object and attempt to use it as a subtype of an interface.

    [1] 25│     query<R>(
        26│         config: string,
        27│     ): Promise<ResultSet<R>>,
    [4] 28│     query<Q: Submittable>(
        29│         config: Q,
        30│     ): Q,
        31│ }
        32│
        33│ declare var c: Client;
        34│
 [2][3] 35│ c.query('SELECT 1');
        36│ c.query({submit: () => undefined});
        37│



Found 1 error

This form exposes the fact that both branches failed speculation, with explanation for each.

---

I guess because the c.query({submit: () => undefined}); line worked without any type argument,

Just to make sure that the value added with LTI is clear here: Before (so selecting version 0.197 in the dropdown for example), if you had

c.query<_>('SELECT 1');

and hover over the _, you'd notice the type empty. We consider this behavior problematic because it is rather unlikely that one would want the inferred type for R to be compatible with any type at the same time (as is the case with empty).

---

I can see some potential avenues for improvement:

1. always show all branches in situations like this.
2. make [underconstrained-implicit-instantiation] not be a fatal error for selecting the overload. This way we'd select the "right" overload (1st), but still error requesting an annotation for R.

[darichey]

The overload seems to lead to a worse error message, but even without the overload, this code will not work, because R is underconstrained.

Either add explicit type arguments or cast the expression to your expected type.

Following this advice from the better error message fixes the error also in the presence of the overload.

[mwiencek]

Thanks @darichey. It was indeed the error message that threw me off.

I guess because the c.query({submit: () => undefined}); line worked without any type argument, I didn't expect the string one to. I'm not familiar enough with the new system to understand why the second call doesn't require one.

[darichey]

Flow needs to determine the types of type parameters at the call site. c.query('SELECT 1'); selects the first overload, but R cannot be determined from this call alone. By contrast, c.query({submit: () => undefined}); selects the second overload in which Q is determined by the argument. Here's a couple more examples.

But the error message is still bad!