Previously it was erroneously treating such invalid interpolation segment as 'incomplete',
even though additional user input, will not 'complete' it.
rdar://28498239
In rare corner cases the pass merged two functions which contain incompatible call instructions.
See source comment in the change for details.
rdar://problem/43051718
This allows us to dump it in the generated interface, though it's
still not syntax-highlighted. This is necessary for textual module
interfaces, but it's also just a longstanding request for Xcode's
"Generated Interface" / "Jump to Definition" feature.
rdar://problem/18675831
* For methods, un-curry function interface type so we can get declared
return type.
* For closures, fall back to getting explicit result type in case we
cannot retrieve it from the type of closure itself.
This test has been failing on the oss-swift_tools-RA_stdlib-DA_test-simulator
bot for more than a week. I finally managed to reproduce the failure
locally, so I am now disabling the test to get the bot passing again.
This either became dead shortly after the removal of Swift 3
compatibility mode from the constraint solver, or even earlier.
Note that the code completion test change is actually correct
because (Any) -> () is not convertible to () -> () in the
language.
If generic parameter associated with missing conformance comes
from different context diagnose the problem as "referencing" a
specific declaration from affected type.
In some cases, such as when pushing a collection conversion down to per-element conversions, we'll coerce a subtype metatype to AnyObject, as in:
```
func f(_: [AnyObject]) {}
f([NSString.self, NSObject.self]) // Type checks as [NSObject.Type] converted to [AnyObject]
```
and only record the restriction kinds used in the indirect steps NSString -> NSObject and NSObject.Type -> AnyObject without recording the jump from NSString.Type to AnyObject. coerceToType ought to apply this subtyping rule even without such a hint, though, since the restriction kind is intended only as an optimization. Fixes rdar://problem/42666956 .
Instead of simply pointing out which type had conformance failures,
let's use affected declaration instead, which makes diagnostics much
richer e.g.
```
'List<[S], S.Id>' requires that 'S.Id' conform to 'Hashable'
```
versus
```
initializer 'init(_🆔)' requires that 'E' conform to 'Hashable' [with 'E' = 'S.Id']
```
Since latter message uses information about declaration, it can also
point to it in the source. That makes is much easier to understand when
problem is related to overloaded (function) declarations.
We cannot use field offset globals if *any* field of a generic class
with Objective-C ancestry is dependent.
This is because the Swift runtime first performs layout starting
from a static instance start offset, and then asks the Objective-C
runtime to slide the offsets based on the dynamic superclass size.
So if the class has a field of generic type, the alignment of that
type can change the offsets of fields *before* it as well as after.
So we cannot assuem that any fields in such a class have the same
offset across instantiations at all.
The previous fix captured the intent of the above, but it only
kicked in if the immediate superclass of the class was imported
from Objective-C. But really we need to do this for any class with
Objective-C ancestry.
While fixing this, re-organize the code in ClassLayoutBuilder a
little bit to untangle the stored property iteration from the
interesting FieldAccess adjustments that take place after.
Since constraint solver has been improved to diagnose more problems
via "fixes", sometimes applying fixes might lead to producing solutions
which are completely ambiguous when compared to each other, and/or are
incomparable, which leads to `findBestSolutions` erasing all of them
while trying to compute best "partial" solution, which is incorrect.
Resolves: rdar://problem/42678836
TypeBase::usesNativeReferenceCounting() was doing a lot of work to
find the class that a type refers to, then determine whether it
would use the native reference-counting scheme. Its primary caller
in IRGen would use an overly-conservative approximation to decide
between the “Objective-C” and “unknown” cases, which resulted in
uses of “unknown” reference counting for some obviously-ObjC cases
(e.g., values of “NSObject”).
Moreover, the approximation would try to call into the type checker
(because it relied unnecessarily on the superclass *type* of a class
declaration), causing an assertion.
Fixes rdar://problem/42828798.
This checks that all combinations of optimized & non-optimized, and whole-module
optimization & incremental compilation give the same result, on a module where
this is actually interesting (i.e. has multiple files so the behaviour differs
between the two).
The information about whether a variable/property is initialized is lost in the
public interface, but is, unfortunately, required because it results in a symbol
for the initializer (if a class/struct `init` is inlined, it will call
initializers for properties that it doesn't initialize itself). This is
important to preserve for TBD file generation.
Using an attribute rather than just a bit on the VarDecl means this fits into
the scheme for module interfaces: textual/valid Swift.
Use the declaration-based name lookup facilities to re-implement
ProtocolDecl::getInheritedProtocols(), rather than dynamically selecting
between the requirement signature and the inherited types. This reduces
dependencies for this computation down to basic name lookup (no semantic
analysis) and gives us a stable result.
