These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
* [TypeChecker] Enclosing stubs protocol note within editor mode
* [test] Removing note from test where there is no -diagnostics-editor-mode flag
* Formatting modified code
* [tests] Fixing tests under validation-tests
Under non-editor mode, the fixit for inserting protocol stubs is associated with a note
pointing to the missing protocol member declaration which could stay in a separate file from
the conforming type, leading to the behavior of rdar://51534405. This change checks if
the fixit is in a separate file and issues another note to carry the fixit if so.
rdar://51534405
This is legal Objective-C code:
typedef NSBar <NSFooing> BarAndFoo
@interface MyBaz : BarAndFoo
@end
// Equivalent
@interface MyBaz : NSBar <NSFooing>
@end
In Swift 3, we usually handled these by just dropping the protocol
part, making everything appear to work. (The protocols get added to
the class later, without looking at sugar.) However, in Swift 4, we
started supporting these compositions directly* and suddenly
inheriting from them didn't work (read: crashed the compiler). As an
extra twist, even Swift 3 can hit the problem case when the base type
is NSObject, because we figured 'id <NSObject, NSFooing>' was a better
approximation of 'NSObject <NSFooing> *' than 'NSObject *' was.
Fix this by just ignoring protocols when looking for a superclass. As
mentioned, we attach those separately anyway, so we aren't losing any
information.
* This isn't exactly true; there's still a difference between
'NSBar <NSFooing>' and 'NSBar <NSFooing> *'. Jacopo Andrea Giola fixed
a previous issue with this in a598277ad. But Swift doesn't do anything
meaningful with the first form, so it usually just pretends it's the
second.
rdar://problem/34586035
When performing a lookup into a class C, we might find a member of
C that witnesses a requirement in a protocol Q that C conforms to.
In this case, AST name lookup returns both results.
There are two further levels of fitering which can eliminate the
ambiguity:
- Sema name lookup maps requirements to witnesses if the base type
of the lookup is a nominal type or a class-constrained archetype.
Imported conformances don't have this mapping recorded, but there's
another hack in this code path where if a requirement maps to
itself inside a conformance, it is dropped from the results
altogether.
- If the duplicate results were not filtered out in Sema name lookup,
there was another hack in CSRanking which would a witness higher
than it's requirement when comparing solutions. This doesn't work
for imported conformances, but usually name lookup filters out
the duplicate results sooner, which also eliminates the exponential
behavior from having multiple constraint system solutions.
However, if we have a subclass existential C & P where C conforms
to Q and we find a member of C that witnesses a requirement of Q,
then (C & P) does not conform to Q.
So if the conformance was imported, *both* of the above checks
would fail to disambiguate the witness and requirement, and the
member access would fail to type check.
To make this work with imported conformances, teach Sema name lookup
to extract the superclass from an existential before performing the
conformance check. If the conformance check fails, it means we
found the protocol member via the 'existential' part of the subclass
existential (eg, in our case, a member of P), and we proceed as
before.
Fixes <rdar://problem/33291112>.
In Swift 3, an Objective-C type like SomeClass <SomeProtocol> is
imported as SomeClass. The protocol qualification is erased unless
the class bound is 'id' or 'Class'.
Importing such types as class-constrained existentials is a source
breaking change, so the new behavior is only enabled in Swift 4
mode.
Furthermore as a transitional step the staging flag
-enable-experimental-subclass-existentials has to be passed in
also. The flag will soon be removed.
