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
Two problems here:
- The InterpolatedString instance variable was not always initialized before
being checked for null
- In the non-null case, we were assuming the result of CallExpr::getCalledValue()
was non-null, but it's null if the callee is not a function declaration
Fixes <rdar://problem/46973064>.
This makes diagnostics more verbose and accurate, because
it's possible to distinguish how many parameters there are
based on the message itself.
Also there are multiple diagnostic messages in a format of
`<descriptive-kind> <decl-name> ...` that get printed as
e.g. `subscript 'subscript'` if empty labels are omitted.
We previously allowed these closures to default to (), but be inferred
as other types as well, which means that we will find some expressions
to be ambiguous because we end up finding multiple viable solutions
where there is really only one reasonable solution.
Fixes: rdar://problem/42337247
In Swift, wrapping the type of a function parameter in parentheses
never changes its meaning. By this logic,
func foo(x: (inout Int))
should be equivalent to
func foo(x: inout Int)
This worked in Swift 4.1 but regressed when the new function type
representation was introduced.
The verifier asserts that declarations whose interface type contains an error
are invalid, so let's just mark them invalid when we set the interface type,
instead of needlessly duplicating this logic all over the declaration checker.
We still had unavailable versions of these for floating-point types
only. We shouldn't need to keep these around, and can instead just
emit a helpful diagnostic for anyone that attempts to use them.
Unfortunately I don't see any way for the diagnostic to produce an
actual fix-it, so it just suggests '+= 1' or '-= 1' without actually
producing a fix.
In Swift 4, constructors had the same name as properties,
methods and enum cases named `init`. This meant that you
could use constructor syntax to call such a member, which
caused some confusing behavior.
Recently I added a special declname for `init` so that
constructors have unique names distinct from any name you
can spell, and "foo.init" syntax would look for a member
with the special name rather than one named `init`.
Unfortunately people actually had code where they defined
members named `init` and then use them via normal member
lookup syntax, like this:
enum E {
case `init`
}
let e: E = E.init
So to maintain backward compatibility, hack member lookup
to also find members named `init` when looking up the special
declname for constructors.
The workaround is only enabled in Swift 4 and 4.2 mode;
in Swift 5 mode you are expected to write "foo.`init`" to access
non-constructor members named `init`.
Fixes <rdar://problem/38682258>.
The only code we should be diagnosing on in such a context is within the property's initialiser expression that has been transplanted from the var's pattern binding decl. We don't perform the analysis on the init expr while it's still a part of the original PBD, as it doesn't get a solution applied there.
Apply exprs in initialiser expressions for lazy properties were being incorrectly marked as not throwing due to the fact that initialiser expressions for lazy properties don't have a solution applied to them until they get type checked as a part of the synthesised getter.
