Resolves: https://bugs.swift.org/browse/SR-4426
* Make IfConfigDecl be able to hold ASTNodes
* Parse #if as IfConfigDecl
* Stop enclosing toplevel #if into TopLevelCodeDecl.
* Eliminate IfConfigStmt
Now that SILGen can correctly lower lvalue accesses of
class existential payloads, remove a hack in Sema that
was simply doing the wrong thing.
Fixes <rdar://problem/31858378>.
Properly diagnose cases of function/subscript argument tuple
structuring/destructuring related by not limited to SE-0110.
Resolves: rdar://problem/31973368
The GenericSignatureBuilder requires `finalize()` to be called before a
generic signature can be retrieved with `getGenericSignature()`. Most of the former isn’t strictly needed unless you want a generic signature, and the
latter is potentially expensive. `computeGenericSignature()` combines the two
operations together, since they are conceptually related. Update most of the
callers to the former two functions to use `computeGenericSignature()`.
This is a bit more robust and user-friendly than hoping more brittle recovery in SILGen or IRGen for unsupported components kicks in. rdar://problem/32200714
Add `FailureDiagnostics::visitKeyPathExpr` to try and diagnose contextual
value type problems related to Smart KeyPath feature. If problems with
contextual value type can't be diagnosed let's walk components and see
if there are any structural problems with expression itself e.g. unknown
members and incorrect types in the path.
Resolves: rdar://problem/32101765
This reverts commit
ecfa406fc5, which was reinstating
3c5b393e0c.
It does not revert one test change from that commit, because
inexplicably one of the tests is still failing, probably due to some
other changes that have happened since. I'm leaving a ticket open to
investigate.
I've added one of the new cases that is failing as a result of this
change.
This is being reverted not because of bugs in this particular commit,
but because it seems to be exposing other bugs in the type checker that
are resulting in source compatibility problems. We need to shake these
other bugs out of the type checker before bringing this change back.
When we have a Substring-to-String conversion as a result of
subscripting in a context expecting String, we emit the rather generic
and unactionable availability diagnostic.
Instead, to aid in migration, emit a highly specialized diagnostic and
fixit when we're compiling for -swift-version 4.
* Give Sequence a top-level Element, constrain Iterator to match
* Remove many instances of Iterator.
* Fixed various hard-coded tests
* XFAIL a few tests that need further investigation
* Change assoc type for arrayLiteralConvertible
* Mop up remaining "better expressed as a where clause" warnings
* Fix UnicodeDecoders prototype test
* Fix UIntBuffer
* Fix hard-coded Element identifier in CSDiag
* Fix up more tests
* Account for flatMap changes
```swift
func foo(f: Void) -> ()) {}
```
This compiler currently suggests we change this to:
```swift
func foo(f: (Void) -> ()) {}
```
That's `(()) -> ()`, almost certainly not what someone wants in Swift
4. We should suggest changing that to:
```swift
func foo(f: () -> ()) {}
```
Additionally,
```swift
func foo(f: (Void) -> ()) {}
```
Should trigger a warning that the `(Void)` input type is `(())`, and you
can't supply `()` to it in Swift 4, and suggest a fix-it change it to:
```swift
func foo(f: () -> ()) {}
```
rdar://problem/32143617
When casting from an object type to a bridged Swift value type, classifyDynamicCast would use the cast classification for the target type's bridged object type, which would be trivially WillSucceed for thinks like NSNumber-to-Int or NSError-to-SomeError, even though the bridging itself could fail. Fixing this fixes SR-2920|rdar://problem/31404281.
Fix a silly gap in my fix for rdar://problem/31104415, where imported
types that gain conformances through their overlays were still getting
errors. Fixes SR-4820 / rdar://problem/32134724.
The "skip generic operators" heuristic within the constraint solver is
fairly awful, because it is known to miss reasonable solutions. Make
is slightly more narrow by only skipping generic operators when the
concrete operator we found was symmetric.
When errors occur in the processing of expressions, we can end up with
invalid ASTs where the application of an operator declared within a
type is missing its "self" argument. Tolerate such ASTs in the
error-handling checker.
`FailureDiagnosis::visitUnresolvedMemberExpr` tries to use the same logic
as `diagnoseSingleCandidateFailures` so instead of doing that let's remove
some of the special handling and use `diagnoseSingleCandidateFailures`
directly instead, which improves label diagnostics and handles more erroneous
cases as well.
Resolves: rdar://problem/31898542
The "common return type" optimization that occurs at
constraint-generation time was overly complicated and wrong in a
couple of places. Fix up these issues:
* Don't cache information about this optimization in the decls
themselves; it ignores visibility as well as invalidation that
occurs in script mode and playgrounds. Just do the the work again
* Don't map type into context; we can bail out when there are type
parameters present
* Skip the "self" parameters of operators in types (since this only
ever occurs for operators).
Longer term, this optimization should move into the solver itself. But
for now, at least it's cleaner/more correct.
This was added at some point with the associated type where
clause work, but it appears to be unnecessary, because all
the tests passed with this removed.
It also introduced a source compatibility issue where we
stopped accepting typealiases to protocol compositions in
protocol inheritance clauses.
Add a test for this case too, since it wasn't tested before.
Fixes <https://bugs.swift.org/browse/SR-4855>.
Previously we allowed this:
protocol HasSelf {
func foo(_: Self)
}
typealias Alias = HasSelf
But not this:
struct Outer {
typealias Alias = HasSelf
}
Lift this restriction since the new String implementation
wants to make use of it.
An early optimization in constraint generation attempted to simplify
type construction (e.g., X(...)) when the type in question has no
failable initializers. However, the optimization didn't appropriately
clear out the cached bit when new information became available (e.g.,
new conformances, new extensions), and didn't seem to help anything
performance-wise (type-checking times didn't increase at all when I
turned this off).
Fixes rdar://problem/30588177.
This isn't an inherent limitation of the language---in fact, it would
be a problem for library evolution if you had to know a superclass's
full vtable contents to generate the vtable for a subclass. However,
that's exactly where we are today, and that's not going to change for
Swift 4.
One small hole in the Swift 3 / Swift 4 story.
More rdar://problem/31878396
As such, we no longer insert two placeholders for initializers that
need two vtable slots; instead we record that in the
MissingMemberDecl. I can see MissingMemberDecl growing to be something
we'd actually show to users, that can be used for other kinds of
declarations that don't have vtable entries, but for now I'm not going
to worry about any of that.
When determining whether one constructor pattern is a subspace of
another, we only checked if the right-hand subspace was larger than the
left. If the left is larger than the right then we can short-circuit
the comparison once more because it cannot be a subspace.
This also takes care of refutable casts in patterns tripping the
duplicate case warning.
