Fix destructuring control flow analysis

[Anders Hejlsberg (ahejlsberg)]

This PR fixes multiple issues related to control flow analysis of destructuring declarations and assignments. Intuitively, for type checking purposes the following should always be true:

• obj.x is equivalent to obj["x"] (property access vs. element access)
• let { x } = obj is equivalent to let x = obj.x (destructuring declaration)
• { x } = obj is equivalent to x = obj.x (destructuring assignment)

However, there were several situations where this was not the case:

functionf1(obj: {a: string|undefined}){if(obj.a){obj={a: undefined};leta1=obj["a"];// string (Incorrect)leta2=obj.a;// string | undefined}}functionf2(obj: [number,string]|null[]){leta0=obj[0];// number | nullleta1=obj[1];// string | nulllet[b0,b1]=obj;// string | number | null (Incorrect)([a0,a1]=obj);// Error (Incorrect)if(obj[0]&&obj[1]){letc0=obj[0];// numberletc1=obj[1];// stringlet[d0,d1]=obj;// string | number | null (Incorrect)([c0,c1]=obj);// Error (Incorrect)}}functionf3(obj: {a?: number,b?: string}){if(obj.a&&obj.b){let{ a, b }=obj;// number, string({ a, b }=obj);// Error (Incorrect)}}functionf4(){letx: boolean;({ x }=0);({["x"]: x}=0);({["x"+""]: x}=0);// No error (Incorrect)}

This PR fixes all of the above. The PR changes type checking for destructuring declarations and assignments to consistently use getIndexedAccessType to compute the destructured type and getFlowTypeOfReference on a synthetic element access expression to compute the control flow type. Furthermore, the PR properly unifies all handing of property access expressions (obj.x) and element access expressions (obj["x"]) in control flow analysis, and removes the increasingly convoluted logic we needed to handle binding elements from destructuring declarations and object and array literals from destructuring assignments (they now become synthetic element access expressions).

Fixes#26379.
Fixes#28792.

[Wesley Wigham (weswigham)]

This error message change is a regression, I believe. An explicit tuple length error here is quite desirable.

[Anders Hejlsberg (ahejlsberg)]

I think the new error is just as good, if not better, and certainly more consistent. I always found this particular message strange as there isn't actually a tuple being assigned to. If we think it is important, we could instead improve the message we give when accessing an out-of-range tuple element in getIndexedAccessType.

[Wesley Wigham (weswigham)]

We explicitly added the tuple length error message to override the message it regressed to. Changing getIndexedAccessType to use it seems kinda appropriate.

[Daniel Rosenwasser (DanielRosenwasser)]

I think it would be nice to give a more specific error message if it can still be rewired into getIndexedAccessType:

Tuple type '{0}' of length '{1}' has no element at index '{2}'.
Seems pretty reasonable.

[Jordi Oliveras Rovira (j-oliveras)]

I think, like Daniel, that will be better message to avoid issues like #29058.

[Wesley Wigham (weswigham)]

While we're here, we should probably change this to isStringOrNumericLiteralLike so NoSubstitutionTemplateLiterals can act like string literals.

[Wesley Wigham (weswigham)]

The results of getAccessedPropertyName need to be more strongly inspected - it seems like the results are normally checked with a truthiness check, which will be incorrect for properties named by the empty string. It also looks like some explicit tuple length errors have been replaced with some worse errors - we probably shouldn't regress there.

[Daniel Rosenwasser (DanielRosenwasser)]

Do we really need to export this from the public API?

[Wesley Wigham (weswigham)]

While I think the error message could still usage a change, this looks OK.

[Anders Hejlsberg (ahejlsberg)]

Daniel Rosenwasser (@DanielRosenwasser)Wesley Wigham (@weswigham) Now with new and improved error message.

[Anders Hejlsberg (ahejlsberg)]

Daniel Rosenwasser (@DanielRosenwasser) And now with no public API changes.