* Nest various top-level Iterator and Index types, and flatten extensions.
* Fix tests from nesting iterator
* Nest Unsafe*BufferPointer.Iterator, extensionify UnsafeBufferPointer
* Degyb LazyCollection
* Nest Flatten iterator and index
Also remove mention of the word “contextual” type from the diagnostic
that rewrites array literals into dictionary literals and scale back
the scope of the diagnostic. This method was catching and
mis-diagnosing too many errors that could better be handled by invalid
conversion diagnostics.
Move associated type inference into its own class, to make this
code easier to understand/maintain/improve. Minor diagnostics changes
because we're properly passing uninference associated type declarations
to the "group" checker.
* Eradicate IndexDistance associated type, replacing with Int everywhere
* Consistently use Int for ExistentialCollection’s IndexDistance type.
* Fix test for IndexDistance removal
* Remove a handful of no-longer-needed explicit types
* Add compatibility shims for non-Int index distances
* Test compatibility shim
* Move IndexDistance typealias into the Collection protocol
This is a nice contained test case that has the goal of testing all
the new functionality. Having this committed before the code changes
will make it clear whether any behavior changes between the old and
new implementation (I expect some small diagnostic changes like
uttering T? instead of T! for some types).
Early on in the development of conditional conformances, we put in a bunch
of assertions for code that uses `conformsToProtocol()` but wasn't handling
conditional conformances. Now, `conformsToProtocol()` handles conditional
conformances by default, and these assertions are tripping up code
that would work.
Remove the assertions and add test cases that used to trip up the
assertions (but now work).
Instead of binding collection types directly let's try to
bind using temporary type variables substituted for element
types, that's going to ensure that subtype relationship is
always preserved.
Resolves: rdar://problem/35541153
Let's not attempt to link arithmetic operators together in
presence of concrete and literal (int, float, string) types.
Resolves: rdar://problem/35740653
For the purposes of partial ordering of declarations (e.g., in
overload resolution), adjust `@autoclosure` parameter types to the
result type of the autoclosure, i.e., the type against which the
argument will be matched. This makes overload resoluton agnostic to
`@autoclosure`.
Fixes SR-6472.
For Swift 3 / 4:
Deprecate the spelling "ImplicitlyUnwrappedOptional", emitting a warning
and suggesting "!" in places where they are allowed according to
SE-0054.
In places where SE-0054 disallowed IUOs but we continued to accept them
in previous compilers, emit a warning suggesting "Optional" or "?" as
an alternative depending on context and treat the IUO as an Optional,
noting this in the diagnostic.
For Swift 5:
Treat "ImplicitlyUnwrappedOptional" as an error, suggesting
"!" in places where they are allowed by SE-0054.
In places where SE-0054 disallowed IUOs, emit an error suggestion
"Optional" or "?" as an alternative depending on context.
Fix problem related to Swift 3 mode (with assertions),
since Swift 3 mode allows passing arguments with extra parens
to parameters which don't expect them, it should be supported
by "deep equality" types e.g. Optional<T>:
```swift
func foo(_: (() -> Void)?) {}
func bar() -> ((()) -> Void)? { return nil }
foo(bar) // This expression should compile in Swift 3 mode
```
Resolves: rdar://problem/35198459
This includes functions without type parameters that are generic
because they are members of a generic context. This addresses a
diagnostics regression because the '==' operators for Optional, Array,
and Dictionary were made into members.
The resulting error message is a little ugly, but is more informative
(and much shorter) than what we had before.
This commit also adds ArrayExpr and DictionaryExpr to the libSyntax nodes
family. Also, it refactors the original parser code for these two
expressions to better fit to the design of SyntaxParsingContext.
This commit has also fixed two crashers.
Remove function-to-function type match score increase, which should only
happen contextually in presence of other restrictions, this used to fix
the case related to matching of arrays of functions with and w/e `throws`
as function parameters which used to be ambigious, and now handled by
collection-upcast conversion score.
Resolves: rdar://problem/35142121
Associated type redeclarations occasionally occur to push around
associated type witness inference. Suppress the warning about redeclarations
that add no requirements (i.e., have neither an inheritance nor a
where clause).
Currently canonicalization of the input type was happening standalone
which means that outer parens are regarded as suger and removed,
this is incorrect after SE-0110 and such parens can't be stripped.
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
Presence of some constraints (Subtype at least) requires a certain
contextual ranking of the type variables associated with them when
it comes to picking bindings, otherwise it might lead to no or
invalid solutions, because only a set of the bindings for the best
type variable is attempted.
Resolves: rdar://problem/22898292
