this is repeated below in the emitter. Extract out a helper 'isDestructuringAssignment' function.

Irony, i know: But this seems much more verbose than before.

however, that's not my major issue with this change. My primary concern is that by writing the code in this manner, it puts the onus on the maintainer to be sure that the saved state is restored properly. The prior form ensured that the state would always get saved/restored properly, and no changes could accidently affect that.

If you are concerned that you need to call parseIdentifierOrPattern with a parameter, and you don't want a lambda allocation, then this is a suitable way to write things:

node.name = inGeneratorParameterContext()
               ? doInYieldContext(parseParameterIdentifierOrPattern)
               : parseParameterIdentifierOrPattern();
...
function parseParameterIdentifierOrPattern() {
    return parseIdentifierOrPattern(SyntaxKind.Parameter);
}

Shouldn't the type be any if the parent type was any?

It is if there is not an initializer. If you're suggesting it should be any regardless of the initializer, then no. Consider:

var a: any;
var [x, y = 1] = a;

Here, a provides no clue as to the intended type of x and y, so we infer from the type of the initializer. This contrasts with:

var a: any;
var [x, y = 1] = [a, a];

Here, the type of a is the intended type for y, and the initializer is required to be assignment compatible with that type.

Do we do that for contextual typing? An analogous example (courtesy of Cyrus Najmabadi (@CyrusNajmabadi)):

var v: (a: any) => void = (a = 1) { a.blah };

Should a in the body be of type any or number? Applying the reasoning you stated from destructuring, it seems like in this example it should be number, not any.

For a parameter the order of precedence is this:

• Explicit type annotation.
• Contextual parameter type.
• Initializer type.

For a binding element it is this:

• Deconstructed type (i.e. the type of the corresponding property or array element in the deconstructed value).
• Type of local default value (initializer) if type of deconstructed value is unknown or any.

So, you can't really apply the reasoning of one to the other. They're different kinds of constructs.

I understand that the way you described is how things are working, but it doesn't seem self explanatory why that is the case. Why are they different constructs?

I assume you agree with the already existing rules for parameters, so I won't try to elaborate on those.

For a destructuring element, the high order bit is the type of the value being deconstructed. Indeed, the initializer isn't even evaluated when a deconstructed value is available. So, this establishes the intuition that the binding element type should primarily come from the corresponding property or element in the deconstructed type. Then, in cases where the type of the deconstructed value isn't known or is any, it makes sense to take a clue from the initializer. That's the next best source of information.

That makes a lot of sense, but why is that not the case for parameters? I don't necessarily agree with the rules for parameters. I buy your argument about the destructuring and would like to apply it to parameters