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.
A protocol extension initializer creates a new instance of the
static type of Self at the call site.
However a convenience initializer in a class is expected to
initialize an instance of the dynamic type of the 'self' value,
because convenience initializers can be inherited by subclasses.
This means that when a convenience initializer delegates to a
protocol extension initializer, we have to substitute the
'Self' type in the protocol extension generic signature with
the DynamicSelfType, and not the static type.
Since the substitution is formed from the type of the 'self'
parameter in the class convenience initializer, the solution is
to change the type of 'self' in a class convenience initializer
to DynamicSelfType, just like we do for methods that return
'Self'.
This fixes cases where we allowed code to type check that
should not type check (if the protocol extension initializer
has 'Self' in contravariant position, and we pass in an
instance of the static type).
It also fixes a miscompile with valid code -- if the protocol
extension initializer was implemented by calling 'Self()',
it would again use the static type and not the dynamic type.
Note that the SILGen change is necessary because Sema now creates
CovariantReturnExprs that convert a static class type to
DynamicSelfType, but the latter lowers to the former at the
SIL level, so we have to peephole away unnecessary unchecked_ref_cast
instructions in this case.
Because this change breaks source compatibility, it is guarded
by a '-swift-version 5' check.
We parse default argument expressions before building a
FuncDecl, so we might see GenericTypeParamDecls that have
not yet been re-parented to the FuncDecl's context.
Fixes <https://bugs.swift.org/browse/SR-5559>,
<rdar://problem/33539464>.
When calling a throwing function without 'try', let's suggest multiple
possibilities of note + fix-it for user to choose from.
Resolves: rdar://problem/33040113
Swift 3 supported limited argument destructuring when it comes to
declaring (trailing) closures. Such behavior has been changed by
SE-0110. This patch aims to provide better error message as well
as fix-it (if structure of the expected and actual arguments matches)
to make the migration easier and disambiguate some of the common
mistakes.
Resolves: SR-4738, SR-4745, rdar://problem/31892961.
We were not enforcing that operators were static if
the operator was defined in a final class, or if it
was defined in a non-final class but the operator was
itself final.
Fixes <rdar://problem/31469036>.
We can't reliably decide in the parser if a type was forgotten or a
wrong type was meant to be a type (e.g. `let x: class MyClass`).
This patch applies a heuristic that the parameter was most likely
forgotten if the next character is a closing bracket or a semantic
separator.
This catches the most common cases of function parameters and variable
declarations that are immediately initialised.
This fixes SR-4785.
* One-sided ranges and RangeExpression
* Remove redundant ClosedRange methods from String
* Fix up brittle tests
* Account for Substring update
* XFAIL range diagnostics on Linux
My original fix for rdar://problem/31794932 didn't work for generic
functions because it was checking in the unsubstituted interface
type. Check structurally instead. Fixes rdar://problem/31794932.
The throw-checking code wasn't properly coping with functions that
take a single, labeled argument, due to the longstanding lie that
pretends that functions take a tuple argument vs. zero or more
separate arguments. Here, the lie manifests as spurious "call can
throw, but is not marked as such" errors.
Fixes rdar://problem/31794932.
In an extension of a nested type, the extended type must be
fully qualified.
Also clean up the diagnostic logic a little bit and centralize
it in diagnoseUnknownType().
Fixes <https://bugs.swift.org/browse/SR-4379>.
foo(_: 3) is equivalent to foo(3), so calling a function that has _ as
an argument label (func foo(`_`: 3)) still requires the _ to be
escaped. Before this patch, the compiler would suggest removing the `s,
even though that changes behaviour.
Fixes rdar://problem/31077797.
rdar://problem/21193574 says that this warning dates back to when closure args before default args used to be considered as trailing closures. This is not the case anymore so Jordan suggested we remove the warning.
Here, the 'self' value has a dynamic Self type, which we must strip
off when performing the conformance lookup.
Fixes <https://bugs.swift.org/browse/SR-2696>.
