It's done by first retrieving all generic parameters from each solution,
filtering boundings into distrinct set and diagnosing any differences.
For example:
```swift
func foo<T>(_: T, _: T) {}
func bar(x: Int, y: Float) {
foo(x, y)
}
```
* diagnostic when a closure parameter is declared with type sugar
* Use a test that was already commmited for SR-11724
i
* Use isa<T> instead of asking for the kind directly
* Fix nit: Remove a whitespace
This commit changes how we represent caller-side
default arguments within the AST. Instead of
directly inserting them into the call-site, use
a DefaultArgumentExpr to refer to them indirectly.
The main goal of this change is to make it such
that the expression type-checker no longer cares
about the difference between caller-side and
callee-side default arguments. In particular, it
no longer cares about whether a caller-side
default argument is well-formed when type-checking
an apply. This is important because any
conversions introduced by the default argument
shouldn't affect the score of the resulting
solution.
Instead, caller-side defaults are now lazily
type-checked when we want to emit them in SILGen.
This is done through introducing a request, and
adjusting the logic in SILGen to be more lenient
with ErrorExprs. Caller-side defaults in primary
files are still also currently checked as a part
of the declaration by `checkDefaultArguments`.
Resolves SR-11085.
Resolves rdar://problem/56144412.
It was being used purely to get the name of the type context for a diagnostic
message. SourceKit's syntactic-only requests were hitting an assertion when
this diagnostic was triggered because they don't set up a type checker.
When SE-110 was being implemented, we accidentally began to accept
closure parameter declarations that had no associated parameter names,
e.g.
foo { ([Int]) in /**/ }
This syntax has never been sanctioned by any version of Swift and should
be banned. However, the change was made long enough ago and there are
enough clients relying on this, that we cannot accept the source break
at the moment. For now, add a bit to ParamDecl that marks a parameter
as destructured, and back out setting the invalid bit on the type repr
for these kinds of declarations.
To prevent further spread of this syntax, stub in a warning that offers
to insert an anonymous parameter.
Resolves part of rdar://56673657 and improves QoI for errors like
rdar://56911630
When it comes to `@autoclosure` parameters we only detect and diagnose
mismatches related to invalid implicit conversions to pointer types. But
`@autoclosure` parameters just like regular ones can have type mismatches
as well which can be handled via recently introduced
`argument-to-parameter mismatch` fix.
We could actually allow this for local functions, but it's not
worth implementing that until the more general ability of local
function default arguments to capture values is implemented.
Fixes <rdar://problem/55119566>.
If the only difference between two functions is `throws` and it
is not a subtype relationship, let's repair the problem by dropping
`throws` attribute and letting solver continue to search for
a solution, which would later be diagnosed.
Introduce a fix to detect and diagnose situations when omitted
generic arguments couldn't be deduced by the solver based on
the enclosing context.
Example:
```swift
struct S<T> {
}
_ = S() // There is not enough context to deduce `T`
```
Resolves: rdar://problem/51203824
* Make Self available to instance member functions (SE-0068?)
* Works for value types and static functions.
* Further experiments with TypeExpr
* Move Self processing off diagnostic path
* diagnostic instead of assertion fail
* TypeExpr of DynamicSelfType now working.
* Update tests for availability of Self
* Cast to Self fixed!
* Self not available as type in classes except for return type
* Could it be this simple?
* Nearly there
* Fix function decls using Self inside methods.
* Fix validation-test/compiler_crashers_2_fixed/0164-sr7989.swift
* Fix of ./validation-test/compiler_crashers_2_fixed/0179-rdar44963974.swift
* "Un-fix" validation-test/compiler_crashers_2_fixed/0164-sr7989.swift
* CHANGELOG entry
* Update CHANGELOG.md
Co-Authored-By: johnno1962 <github@johnholdsworth.com>
* Update CHANGELOG.md
Original fix for SR-9102 stripped throws bit from the function types
nested inside optionals before attempting bindings, that doesn't
work with e.g. default parameter values because conversions from
throwing and non-throwing functions are only allowed in subtype
relationship but function types nested inside optionals are going
to be equated.
So this patch takes an alternative approach and attempts to pattern
match `nil` literal and `.none` use and classify argument as
non-contributing to throws.
Resolves: rdar://problem/47550715
