When building a generic signature, we would drop requirements
where the LHS or RHS was a DependentMemberType with an unresolved
associated type, however we didn't perform the same check for
DependentMemberTypes that are nested inside structural types.
- All parts of the compiler now use ‘P1 & P2’ syntax
- The demangler and AST printer wrap the composition in parens if it is
in a metatype lookup
- IRGen mangles compositions differently
- “protocol<>” is now “swift.Any”
- “protocol<_TP1P,_TP1Q>” is now “_TP1P&_TP1Q”
- Tests cases are updated and added to test the new syntax and mangling
This commit defines the ‘Any’ keyword, implements parsing for composing
types with an infix ‘&’, and provides a fixit to convert ‘protocol<>’
- Updated tests & stdlib for new composition syntax
- Provide errors when compositions used in inheritance.
Any is treated as a contextual keyword. The name ‘Any’
is used emit the empty composition type. We have to
stop user declaring top level types spelled ‘Any’ too.
It looks like the mapTypeIntoContext() call is using the wrong
'dc', because in fact we have no way of knowing what the original
'dc' was which produced the type parameters in question.
Really the problem is we're picking apart SubstitutedType here,
which is almost always the wrong thing to do. I don't think
SubstitutedType should exist at all.
To avoid the crash, just bail-out if 'dc' is not generic.
I'm intentionally avoiding a principled fix here to hasten the
apocalypse when all of CSDiag.cpp will collapse under its own
weight and get rewritten in a sane way.
