Provide more detailed diagnostic message when implicitly synthesized @objc initializer in subclass was overridden inside the subclass' extension
Resolves: rdar://problem/79179597
With the previous resolveTypeInContext() patch, a few compiler
crashers regressed with this problem, presumably because we were now
performing lookups in more contexts than before.
This is a class of problems where we would attempt a recursive
validation:
1) Generic signature validation begins for type T
2) Name lookup in type context finds a non-type declaration D nested in T
3) Generic signature validation begins for D
4) The outer generic context of D is T, but T doesn't have a generic
signature yet
The right way to break such cycles is to implement the iterative
decl checker design. However when the recursion is via name lookup,
we can try to avoid the problem in the first place by not validating
non-type declarations if the client requested a type-only lookup.
Note that there is a small semantic change here, where programs that
were previously rejected as invalid because of name clashes are
now valid. It is arguable if we want to allow stuff like this or not:
class A {
func A(a: A) {}
}
or
class Case {}
enum Foo {
case Case(Case)
}
However at the very least, the new behavior is better because it
gives us an opportunity to add a diagnostic in the right place
later. The old diagnostics were not very good, for example the
second example just yields "use of undeclared type 'Case'".
In other examples, the undeclared type diagnostic would come up
multiple times, or we would generate a cryptic "type 'A' used within
its own definition".
As far as I understand, this should not change behavior of any existing
valid code.
Put in some rudimentary logic for finding circular references within
the iterative type checker and diagnosing those cycles. The
"rudimentary" part is because we're performing linear searches within
a stack rather than keeping a proper dependency graph, which is
inefficient and could display longer cycles than are actually
present. Additionally, the diagnostic is not specialized to the actual
query, so we get a generic "circular reference" diagnostic. OTOH, we
show all of the declarations involved in the cycle, which at least
lets the user figure out where the cycle occurred.
Enable the iterative type checker for resolving the type of a global
typealiases.
Swift SVN r32572
The exact message is mostly immaterial at this point, but without the
change we end up recursively validating the property, marking it invalid,
and then never actually emitting a diagnostic, leaving SILGen and
Serialization to go ahead and fail.
rdar://problem/20913392
Swift SVN r30830
Enhance fixItRemove() to be a bit more careful about what whitespace it leaves around: if the thing it is removing has leading and trailing whitespace already, this nukes an extra space to avoid leaving double spaces or incorrectly indented results.
This includes an extra fix for looking off the start of a buffer, which extractText doesn't and can't handle.
This fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29449
if the thing it is removing has leading and trailing whitespace already, this nukes
an extra space to avoid leaving double spaces or incorrectly indented results. This
fixes <rdar://problem/21045509> Fixit deletes 'let' from non-binding 'if case let' statements, but leaves an extra space
Swift SVN r29419
The diagnostic we were producing was confusing the user into thinking that
you couldn't have a delegating init on a struct. Improve the diagnostic and
add a fixit hint.
Swift SVN r27872
