For call argument completion, if the expected type and completion result type are
both GenericTypeParameterTypes, comparing them doesn't make sense we can't account
for their different contexts at this point in the code, and hit assertions in the
constraint solver if we try.
For now, don't attempt to add a type relation for this case.
Resolves rdar://problem/38153332.
Rename detection in the tool may not reflect overlay additions; thus we
mistakes a new name to be an underscored one. This new action searches
migration scripts for suspicious ones and generates a template for us to
specify the correct names.
This is immensely useful when working on generic code, where the signatures
of (many) functions are all that is required, and removing the bodies makes
things compile faster, allows tools like creduce to work better and results in
less noise in a debugger.
Unfortunately the design of refactoring means this currently only works on a
single top-level decl, or multiple decls inside a type.
The mangler had a bug when mangling associated types so we got
an invalid input. Instead of ignoring the fact it's invalid,
throw an error.
Eventually we'll refactor the visitor to fail at any point in
time, as suggested by Slava, but for now, at least, stop pretending
this is a valid mangling.
This was caused by two separate issues:
1. If given a function type with an IUO return, it would add function call
completions, set Done=true, and then progress to some logic to add
completions for the unwrapped type of optionals. That code would check if
the corresponding decl has the IUO attribute set and, if it was but couldn't
be unwrapped, assert. For function types, it now early exits after adding
call completions.
2. If given the type of a bound (`blah?.`) or forced (`blah!.`) optional,
the type is non-optional and can't be unwrapped and the decl still has the
IUO so it asserts. Refined the assertion to account for this case.
Resolves rdar://problem/38188989.
Rather than relying on the NameAliasType we get by default for references
to non-generic typealiases, use BoundNameAliasType consistently to handle
references to typealiases that are formed by the type checker.
This doesn't have a specific effect now, because all of these places
are likely to only see NameAliasType, but it is refactoring with the
intent of eliminating NameAliasType entirely.
Adrian reported this bug he discovered as part of his
work on improving generics in swift/lldb.
Allocators were treated as `function`, when the demangle
tree suggests they're much more akin to constructors. On
top of that, the code for handling them was commented out,
so type reconstruction was always failing. I'm not entirely
sure this is always correct, but it seems to be an improvement
on what currently type reconstruction does. At least now
we have tests so if something will break, we're going to
notice.
<rdar://problem/38720742>
