Some messages said 'typealias' and others said 'type alias'.
Change everything to use 'type alias' consistently (except
when it's talking about the keyword itself).
As we've done with layout requirements, introduce a new entry point
(addTypeRequirement) that handles unresolved type requirements of the
form `T: U`, resolves the types, and then can
1. Diagnose any immediate problems with the types,
2. Delay the type requirement if one of the types cannot be resolved,
or
3. Break it into one or more "direct" requirements.
This allows us to clean up and centralize a bunch of checking that was
scattered/duplicated across the GSB and type checker.
We want to validate both type in same-type or conformance constraints,
even when the first type is ill-formed, so we don't leave null types
around for later phases to crash on.
Fixes rdar://problem/31093854.
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.
