[Runtime] Fix private generic type witness demangling failure

[beccadax]

This one’s screwily specific—if you have:

• a private generic type,
• with a nested generic type in it,
• and the nested type conforms to a protocol with an associated type,
• and that associated type’s witness is a generic type,
• and some of the witness type’s generic parameters are generic parameters of the nested type,

demangling would fail. The problem is that the substitution machinery in the runtime would consider there to be three, not two, generic context depths involved. Depth 1, which should correspond to the nested type, would instead have no generic parameters. The fix is to skip over depths with zero generic parameters.

Fixes rdar://problem/47773183.

[beccadax]

@swift-ci please test

[beccadax]

Note: This fix works, but I feel like the compiler might actually be generating incorrect metadata too. In the test case, the generic context descriptor appears to include these depths:

0: Anonymous context for private types
1: Parent<ParentType>
2: Nested<First, Second>

But before this bug fix, it was attributing the generic parameters to these depths:

0: ParentType
1: (none)
2: First, Second

It seems to me like the anonymous context probably shouldn't be counted as a depth (its isGeneric flag is set; maybe it shouldn't be?), but my understanding might be flawed.

[jckarter]

Yeah, it should be correct to skip over anonymous contexts, since those are only runtime representation and don't have any correspondence to the depths used by mangled references.