Instead on depending on repr to be a function, let's only check
whether type resolved for `@autoclosure` points to a function type
because it's allowed for `@autoclosure` parameters to be to
wrapped into parens or be represented by a typealias.
Resolves: rdar://problem/65704049
* [Parser] Update 'Confusables.def' file to include confusable and base character names
* [Parser] Add a new utility method to return the names of the confusable and base characters for a given confusable codepoint
* [Parser] Update diagnostic for confusable character during lexing to mention confusable and base character names
* [Sema] If there is just a single confusable character, emit a tailored diagnostic that also mentions the character names
* [Diagnostics] Add new diagnostic messages to the localization file
* [Test] Update confusables test
* [Utils] Update unicode confusables txt file and update script to regenerate confusables def file
* [Parse] Regenerate 'Confusables.def' using updated script
* [Utils] Adjust generate_confusables script based on review feedback
Fix a mistake with name mapping. Updated header comment. Fix a couple of linting issues.
* [Parse] Regenerate 'Confusables.def' file once again after script changes
* [Parse] Add the newline after end of 'getConfusableAndBaseCodepointNames' method
* [Test] Update diagnostic message in 'Syntax/Parser/diags.swift'
* [Diagnostics] Update 'does not override' diagnostic message to include protocol context as well
* [Sema] Check whether the override context is a class or a protocol for diagnostic purposes
* [Test] Update tests with new diagnostic message for overrides in protocol context
* [Sema] Adjust diagnostic for overrides in structs and enums to use the existing 'override_nonclass_decl' diagnostic
Rather than type-checking captures as separate declarations during
pre-check, generate constraints and apply solutions to captures in
the same manner as other pattern bindings within a constraint
system.
Fixes SR-3186 / rdar://problem/64647232.
With the constraint solver preferring backward scanning to forward
scanning, there is no need to point out the ambiguity: we will
always, consistently warn about backward scanning when it produced a
result that was different from the forward scan.
This approach, suggested by Xiaodi Wu, provides better source
compatibility for existing Swift code, by breaking ties in favor of the
existing Swift semantics. Each time the backward-scan rule is needed
(and differs from the forward-scan result), we will produce a warning
+ Fix-It to prepare for Swift 6 where the backward rule can be
removed.
My experiment to improve source compatibility by also performing a
backward scan removed the SE-0286 heuristic that skipped binding
the unlabeled trailing closure to a defaulted parameter when that
would fail. Reinstate that heuristic, which makes more existing code
work with the forward-scan behavior.
This makes my source-compatibility improvements a quality-of-implementation
Whenever we form a call that relies on the deprecated "backward" scan,
produce a warning to note the deprecation along with a Fix-It to label
the parameter appropriately (and suppress the warning). For example:
warning: backward matching of the unlabeled trailing closure is
deprecated; label the argument with 'g' to suppress this warning
trailingClosureEitherDirection { $0 * $1 }
^
(g: )
To better preserve source compatibility, teach the constraint
solver to try both the new forward scanning rule as well as the
backward scanning rule when matching a single, unlabeled trailing
closure. In the extreme case, where the unlabeled trailing closure
matches different parameters with the different rules, and yet both
produce a potential match, introduce a disjunction to explore both
possibilities.
Prefer solutions that involve forward scans to those that involve
backward scans, so we only use the backward scan as a fallback.
SE-0248 changes the backward-scan matching behavior for the unlabeled
trailing closure into a forward scan. In circumstances where this
could silently change the meaning of a call to a particular
function, i.e., when there are two defaulted closure parameters such
that a given closure to match either one of them, produce an warning
that describes the change in behavior. For example:
t4.swift:2:24: warning: since Swift 5.3, unlabeled trailing
closure argument matches parameter 'x' rather than parameter 'z'
trailingClosureSingle2 { $0 }
^
t4.swift:2:24: note: label the argument with 'z' to retain the
pre-Swift 5.3 behavior
trailingClosureSingle2 { $0 }
^
(z: )
t4.swift:2:24: note: label the argument with 'x' to silence this
warning for Swift 5.3 and newer
trailingClosureSingle2 { $0 }
^
(x: )
t4.swift:1:6: note: 'trailingClosureSingle2(x:y:z:)' contains
defaulted closure parameters 'x' and 'z'
func trailingClosureSingle2(x: (Int) -> Int = { $0 } , y: (Int) ->
Int = { $0 }, z: (Int) -> Int = { $0 }) {}
^ ~
This explains the (rare) case where SE-0286 silently changes the
meaning of a program, offering Fix-Its to either restore the
pre-SE-0286 behavior or silence the warning, as appropriate.
Diagnosis for invalid uses of trailing closures has been folded in
with argument-matching diagnostics, so remove all of the machinery
around the syntactic "mismatched trailing closure" logic.
The change to the forward-scanning rule regressed some diagnostics,
because we no longer generated the special "trailing closure mismatch"
diagnostic. Reinstate the special-case "trailing closure mismatch"
diagnostic, but this time do so as part of the normal argument
mismatch diagnostics so it is based on type information.
While here, clean up the handling of missing-argument diagnostics to
deal with (multiple) trailing closures properly, so that we can (e.g)
suggest adding a new labeled trailing closure at the end, rather than
producing nonsensical Fix-Its.
And, note that SR-12291 is broken (again) by the forward-scan matching
rules.
Once the first argument for a variadic function-typed parameter has been
matched, allow an unlabeled trailing closure to match, rather than
banning all uses of the unlabeled trailing closure with variadic
parameters.
The "fuzzy" forward scan matching algorithm was only applied when there
was a single, unlabeled trailing closure, but was disabled in the
presence of multiple trailing closures. Extend the "fuzzy" match to
account for multiple trailing closures, by restricting the search for
"a later parameter that needs an argument" to stop when we find a
parameter that matches the first (labeled) trailing closure.
Introsuce a new "forward" algorithm for trailing closures where
the unlabeled trailing closure argument matches the next parameter in
the parameter list that can accept an unlabeled trailing closure.
The "can accept an unlabeled trailing closure" criteria looks at the
parameter itself. The parameter accepts an unlabeled trailing closure
if all of the following are true:
* The parameter is not 'inout'
* The adjusted type of the parameter (defined below) is a function type
The adjusted type of the parameter is the parameter's type as
declared, after performing two adjustments:
* If the parameter is an @autoclosure, use the result type of the
parameter's declared (function) type, before performing the second
adjustment.
* Remove all outer "optional" types.
For example, the following function illustrates both adjustments to
determine that the parameter "body" accepts an unlabeled trailing
closure:
func doSomething(body: @autoclosure () -> (((Int) -> String)?))
This is a source-breaking change. However, there is a "fuzzy" matching
rule that that addresses the source break we've observed in practice,
where a defaulted closure parameter precedes a non-defaulted closure
parameter:
func doSomethingElse(
onError: ((Error) -> Void)? = nil,
onCompletion: (Int) -> Void
) { }
doSomethingElse { x in
print(x)
}
With the existing "backward" scan rule, the trailing closure matches
onCompletion, and onError is given the default of "nil". With the
forward scanning rule, the trailing closure matches onError, and there
is no "onCompletion" argument, so the call fails.
The fuzzy matching rule proceeds as follows:
* if the call has a single, unlabeled trailing closure argument, and
* the parameter that would match the unlabeled trailing closure
argument has a default, and
* there are parameters *after* that parameter that require an argument
(i.e., they are not variadic and do not have a default argument)
then the forward scan skips this parameter and considers the next
parameter that could accept the unlabeled trailing closure.
Note that APIs like doSomethingElse(onError:onCompletion:) above
should probably be reworked to put the defaulted parameters at the
end, which works better with the forward scan and with multiple
trailing closures:
func doSomethingElseBetter(
onCompletion: (Int) -> Void,
onError: ((Error) -> Void)? = nil
) { }
doSomethingElseBetter { x in
print(x)
}
doSomethingElseBetter { x in
print(x)
} onError: { error in
throw error
}
If we're matching the trailing closure at the end but haven't seen any
mismatches yet, consider the trailing closure to be a mismatch.
This function probably needs to be rewritten in terms of
matchCallArguments(), because it is performing an incorrect
approximation of label matching that doesn't work for multiple
trailing closures.
While generating constraints for `SuperRefExpr` generator has to figure out
a type of superclass associated with a current reference. Doing so might
produce an empty type (aka `Type()`) when resolution fails, so `getSuperType`
needs to check whether type is valid before attempting to wrap it into `MetatypeType`.
Resolves: rdar://problem/50819554
This change permits a subclass to redeclare an unavailable member from a superclass. For instance, suppose you write this code (or, more likely, a version where `Base` is an ObjC class):
```swift
class Base {
@available(*, unavailable) init() {}
}
class Derived: Base {
/* override */ init() {}
}
```
Previously, Swift would reject `Derived.init()` without the `override` keyword, telling you that you should add it, but it would also reject it *with* the `override` keyword, telling you that you can't override something that's unavailable. This PR makes Swift accept it without the `override` keyword; declaring it with the keyword is still forbidden.
Fixes rdar://65702529.
After the TypeLocs were removed here, the TypeRepr from the IsExpr was
the only thing providing access to syntactic information from the parent
IsExpr. In order to support this, it was possible to construct a bizarre
ConditionalCheckedCastExpr that contained both semantic and syntactic
information. This doesn't comport with the rest of the casting nodes,
which force you to pick one or the other.
Since we're rewriting an IsExpr into a EnumIsCaseExpr, let's just stash
the syntactic information there. This unblocks a bit of cleanup.
Edge contraction was being performed for Bind, Equal,
BindToPointerType, and BindParam constraints. However, it's behavior
on everything but BindParam is the same as what matchTypes() already
does, so only look at BindParam constraints. This simplifies the code
but shouldn't change its behavior.
Add a function that deals with invoking syntactic
diagnostics for all the expressions involved in
a SolutionApplicationTarget.
Resolves SR-13260
Resolves rdar://65903005
