Tuple rest sandwich prop

[craigphicks]

This is for analytic use with issue #49105 (reopened in short form as #49138).

The analysis is complete and the results are written below. The code is no longer being worked on. It remains as a "pull draft" merely fpr analysis purposes.

To summarize the analysis, the way the code is currently written (4.7) there is assumption that array context types
don't necessarily need to expose a length for use in matching. However that won't necessarily work when
trying to match with a bidirectional search. Might be able to get away with negative indices
(distance from the end) and still avoid length. But stretching a rest element to infinite length won't work when a bidirectional search is required.

[craigphicks]

The code is functionally correct with respect to the baselines tests.

However, the following two kinds of contextualType currently exist in the baseline examples, and end up being passed to checkArrayLiteral but never in a way that invokes the reverse part of the bidirectional search.

• contextualType && !isTupleLikeType(contextualTypes && isTupleLikeType(contextualTypes)
• contextualType && !!(contextualType.flags & TypeFlafs.Union)

Here's how length gets handled for those cases:

 const getContextualTypeForElementExpression_altLength=(arrayContextualType: Readonly<Type>): number => {
    Debug.assert(!!arrayContextualType,"!!arrayContextualType");
    if (isTupleType(arrayContextualType)) {
        return arrayContextualType.target.elementFlags.length;
    }
    else if (isTupleLikeType(arrayContextualType)) {
        return maxContextualTypeLength; // It doesn't have to be like this.  There really is a length.
    }
    else if (!!(arrayContextualType.flags && TypeFlags.Union)) {
        return maxContextualTypeLength; // What's going on here???
    }
    else {
        return 1; //  This is an array, am I right?
    }
};

Certainly (I think) at least we could make a test with a TupleLikeType that requires the birectional search. But because we're not currently returning a real length, that kind of test could fail.

Also, as for Unions, I haven't fully analyzed those cases but it is definitely the case a imposing a lenght of 1 causes the some baseline tests to return different type results. (However, in limited testing, didn't notice any actual error yes/no differences.) We also need to consider whether those kinds of tests would need bidirectional search - by default I think the answer should be yes.

[craigphicks]

• getContextualTypeForElementExpression_altTypeAndFlag
• getContextualTypeForElementExpression_altLength
• getContextualTypeForElementExpression_altFlags

are workarounds for getContextualTypeForElementExpression which fails when accessing indices beyond the first
index corresponding to a rest index. getContextualTypeForElementExpression returns the value at the first rest index for any index value >= the first rest index. That doesn't work when there are real values beyond the first rest index, which are actually allowed in the current code from createNormalizedTupleType: (checker.ts: function createNormalizedTupleType), see the code corresponding to comments:
// Turn optional elements preceding the last required element into required elements
// Turn elements between first rest and last optional/rest into a single rest element
Proposal: IF an abstract representation is necessary (is it necessary?)
then modify getContextualTypeForElementExpression to accept negeative indices, where -n refers to the nth element from the end, starting at -1. (Same numbering convention as slice).

NOTE!!!
The condition (contextualType.target.elementFlags.length < getTypeArguments(contextualType).length) does occur. It has been observed tp happen when there is tuple type which an unknow generic type in, e.g., [...T] followed by an instantiation of that type, e.g. [...T] = ["hello"]. (There may or may not be other examples), Then the types contained in getTypeArguments(contextualType) are [string, T] (length 2) but contextualType.target.elementFlags is [ElementFlags.Required] (length 1).

Conformance in length is required when reading from the ends of the arrays.

[Mifrill]

Suggested change

	// Type T12 IS a rest sandwich format - this example shows results that improvably differ between before and after.
	// Type T12 IS a rest sandwich format - this example shows results that improbably differ between before and after.

[sandersn]

The bug for this PR was fixed in 5.0, so I'm going to close it. Please let me know if it needs to be re-opened.