Fuzzing found a problem related to re-typecheck introducing
`MemeberRefExpr` into AST with failing requirements which
are then diagnosted via fixes, quite unlikely case to be
found in the wild.
We failed to properly classify arguments that are of optional function
type, in this case leading to a verification failure due to the throws
attribute on the apply expression not being set to some value.
Fixes: SR-9102 / rdar://problem/45615204
I have a follow-up change to correctly classify optional arguments,
and with that fix applied we incorrectly emit rethrow diagnostics for
'nil' arguments passed in places where optional throwing functions are
expected.
This change ensures that we strip the throwing bit off of the nested
function type so that we don't consider 'nil' arguments in these
positions as potentially throwing functions.
When conformance checking infers an associated type, it makes a new
typealias to represent that type. Unfortunately, the access of that
typealias was always the same as the conforming type's, which (1)
might have leaked implementation details if the protocol wasn't as
public as the conforming type, and (2) might have been straight-up
incorrect if the /inferred type/ wasn't as public as the conforming
type.
Fix this in pre-Swift-5 modes by limiting the access to fit the
underlying type (technically source-breaking, but most code that
relied on this would have failed to link anyway), and in Swift 5 mode
by using the minimum possible access (the intersection of the protocol
and conforming type).
rdar://problem/46143405
Closures can't explicitly capture a mutating self parameter, so
let's re-word diagnostic to point what what actual problem here
is, and add a note about ways to fix the code.
Thanks to Cory Benfield for message suggestion.
Resolves: [SR-9314](https://bugs.swift.org/browse/SR-9314)
Resolves: rdar://problem/46322943
While matching two metatypes where one side is a class (which could have
supertypes) and another is a type variable use `subtype` constraint to
delay binding types together because there is a real possibility that
there exists a superclass associated with yet free type variable which
would be a better match when attempted.
Resolves: rdar://problem/44816848
We were trying to do this when synthesizing the getter prototype, but
we don't do that immediately when we're just type-checking a reference
to the storage, which could lead to the reference thinking that the
getter was non-mutating.
Fixes rdar://45712204.
In postfix completion, for operator completion, we do:
1. Type check the operand without applying it, but set the resolved
type to the root of the expression.
2. For each possible operators:
i. Build temporary binary/postfix expression
ii. Perform type checking to see whether the operator is applicable
This could be very slow especially if the operand is complex.
* Introduce `ReusePrecheckedType` option to constraint system. With
this option, CSGen respects pre-stored types in expressions and doesn't
take its sub-expressions into account.
* Improve type checking performance because type variables aren't
generated for sub-expressions of LHS (45511835)
* Guarantee that the operand is not modified by the type checker because
expression walkers in `CSGen` doesn't walk into the operand.
* Introduce `TypeChecker::findLHS()` to find LHS for a infix operator from
pre-folded expression. We used to `foldSequence()` temporary
`SequenceExpr` and find 'CodeCompletionExpr' for each attempt.
* No need to flatten folded expression after initial type-checking.
* Save memory of temporary `BinaryExpr` which used to be allocated by
`foldSequence()`.
* Improve accuracy of the completion. `foldSequence()` recovers invalid
combination of operators by `left` associative manner (with
diagnostics). This used to cause false-positive results. For instance,
`a == b <HERE>` used to suggest `==` operator. `findLHS()` returns
`nullptr` for such invalid combination.
rdar://problem/45511835
https://bugs.swift.org/browse/SR-9061
Suggest to add `()` (form a call) to correctly forward argument function
originated from `@autoclosure` parameter to function parameter itself
marked as `@autoclosure`.
Currently logic in `matchCallArguments` could only detect argument
being an @autoclosure parameter for normal calls and operators.
This patch extends it to support subscripts and unresolved member calls.
We try to work more-or-less bottom up in the expression when we
attempt apply disjunctions first. This is very helpful to get good
results with designated types enabled in the solver. Rather than
forcing tests to specify both `-swift-version 5` (which also enables
this bottom-up behavior) and enabling designated types, allow them to
just enable the later to get the behavior.
We'll eventually have to revisit this when we decide the specific
conditions that we'll enable the use of designated types under.
Instead of passing in a DeclContext, which we don't have when emitting a keypath
accessor, pass in a ModuleDecl and ResilienceExpansion.
Keypaths now work well enough in inlinable contexts that we can check in an
end-to-end resilience test.
Also add overloads for these operators to an extension of Array.
This allows us to typecheck array concatenation quickly with
designated type support enabled and the remaining type checker hacks
disabled.
* Emit a warning diagnostic if an extension contains a redundant requirement
* Updates diagnostic message and checks if the extension type is a protocol
* Updates indentation and extracts self type
* [ast] Updates diagnostic message
* [ast] fix indentation
* [ast] Change ':' to 'to' in 'protocol_extension_redundant_requirement'
* [sema] Adds protocol extension redundant requirement check
Moved from TypeCheckRequests to TypeCheckGeneric
* [ast] fix some crashes related to null ptrs, check self type before emitting a diagnostic, update tests
* [ast] renames 'owner' to 'ext'
* [sema] fix style
* [test] Add another test case for redundant requirement
Co-Authored-By: theblixguy <suyashsrijan@outlook.com>
* [test] fix failing test
The test was failing because A has already been declared as a typealias.
This allows us to skip attempting actual conversions.
This speeds up one of our slow test cases, and perturbs the output of
another test. In the latter case, we stop emitting conversions as part
of the non-semantic piece of the array_expr. The fact that we're not
putting conversions in on that path is something I've seen before in
other instances. I'll open a bug if I cannot find one for it, although
I believe it's entirely cosmetic in this case since we don't rely on
the conversion being there.
This allows us to skip attempting actual conversions.
This speeds up one of our slow test cases, and perturbs the output of
another test. In the latter case, we stop emitting conversions as part
of the non-semantic piece of the array_expr. The fact that we're not
putting conversions in on that path is something I've seen before in
other instances. I'll open a bug if I cannot find one for it, although
I believe it's entirely cosmetic in this case since we don't rely on
the conversion being there.
Follow-up to f33bf67dc9 for non-type requirements. We use non-type
witnesses for optimization purposes, so if we didn't enforce this we
might end up with something silently performing worse with parseable
interfaces than it would with swiftmodules. There's also a tricky case
where the client of the interface infers a different implementation:
public protocol Foo {
func foo()
}
extension Foo {
public func foo() { print("default") }
}
@usableFromInline struct FooImpl: Foo {
internal func foo() { print("actual") }
}
There might be another solution to this in the future, but for now
this is the simplest answer. Like f33bf67dc9, it'll be a warning in
Swift 4 mode and an error in Swift 5 mode.
rdar://problem/43824161
