* 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.
We were assuming that variadic parameters are at the end, so we didn't
fill in all the types of the tuple elements in the tuple type we were
constructing.
* [Diagnostics] SR-7445 Improve diagnostics for assignment failures
* modified messages for assignments to function calls,
modified messages for assignments to methods.
removed comment for resolved radar.
* removed extra line and braces
* added tests for assignment_lhs_is_apply_expression
eliminated redundant literal check which is always invoked before call
reverted 'cannot assign to value' for literal assignments in subexpressions
* Complemented assigning to literal tests & reverted to 'cannot asign to value' for methods (was 'cannot assign to member')
* removed extra tabs
* eliminated one more accidental spacing
* Update CSDiag.cpp
* added highlighting, fixed & rechecked tests
* added highlighting for complex expressions involving assigning to literals
Resolves: [SR-7445](https://bugs.swift.org/browse/SR-7445)
1) Formalize "OnAccessor". A hack used to alias this to "OnFunc".
2) New aggregates: OnNominalType, OnGenericType, OnAbstractFunction.
3) Consistent and self-documented (albeit custom) style to ease code review/audits.
4) Removes a few cases of `OnAccessor` based on pull request #16031 feedback.
Continue to emit notes for the candidates, but use different text.
Note that we can emit a typo correction fix-it even if there are
multiple candidates with the same name.
Also, disable typo correction in the migrator, since the operation
is quite expensive, the notes are never presented to the user, and
the fix-its can interfere with the migrator's own edits.
Our general guidance is that fix-its should be added on the main
diagnostic only when the fix-it is highly likely to be correct.
The exact threshold is debateable. Typo correction is certainly
capable of making mistakes, but most of its edits are right, and
when it's wrong it's usually obviously wrong. On balance, I think
this is the right thing to do. For what it's worth, it's also
what we do in Clang.
The Swift class model does not support overriding declarations where either
the overridden declaration or the overriding declaration are in an extension.
However, the Objective-C class model does, so marking the declaration as
@objc (when possible) will work around the limitation.
Customize the "cannot override declaration in extension" diagnostic to
suggest adding @objc to the overridden declaration in cases where
@objc is permitted. Fixes SR-6512 / rdar://problem/35787914.
