Previously, the protocol refinement access control error
would always assume a protocol was being refined. Change it
to instead refer to the appropriate declaration kind.
Resolves SR-9195
There is a small chance that codegen and everything works fine, but the
generated code is wrong because of mismatched expectations on two sides,
so we have some tests to catch that.
Instead of always requiring a call to be made to pass argument
to `@autoclosure` parameter, it should be allowed to pass argument
by value to `@autoclosure` parameter which can return a function
type.
```swift
func foo<T>(_ fn: @autoclosure () -> T) {}
func bar(_ fn: @autoclosure @escaping () -> Int) { foo(fn) }
```
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
Expression patterns (and cast patterns) don't actually contribute to
the exhaustivity of a switch statement---if you're matching against a
String, matching "abc" doesn't meaningfully reduce the full space of
the values you have to match. This was already handled, but didn't do
the right thing in a particular case involving a tuple payload in an
enum after the Space Engine (exhaustivity checker) optimizations that
went out in Swift 5.
https://bugs.swift.org/browse/SR-10301
This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.
Back when SE-0110 was implemented we decided that passing a function value
taking multiple parameters would be allowed where a function value taking
a single tuple argument was expected.
Due to quirks in the old function type representation, the "splat" in the
other direction sometimes worked too. When we redid the function type
representation we added a simulation of the old quirk for -swift-version 4
mode.
However this simulation was itself problematic because it only worked when
the function value being passed was a non-overloaded declaration reference.
Slightly broaden the hack to the overloaded case, to prevent user
confusion when adding or removing overloads.
If the access level of a protocol witness does not satisfies a requirement,
the compiler suggests marking it as the required level. This is not suitable
when the witness is in an extension whose specified access level is less than
the required level, since the fixit fights with other warnings in this case.
This patch identifies such case and produces improved diagnostics.
Resolves: SR-9793
This is reasonable to diagnose with a warning, but dropping the 'open'
down to 'public' isn't the right fix, because now it's not a valid
override. The declaration has to get moved to another extension instead,
or the extension has to not set a default access level.
This turned out to be a source compat issue because the same logic
that emits the fix-it also updates the access of the member, which
then resulted in "must be as accessible as the declaration it
overrides" in the /same/ build. It's not immediately clear what caused
this; probably something's just being validated in a different order
than it was before. The change makes sense either way.
Stepping back, it's weird that a warning would change how the compiler
saw the code, and while we could check for 'override' explicitly, we
can't know if the member might be satisfying a protocol requirement.
Better to just not guess at the right answer here.
rdar://problem/47557376&28493971
Try to fix constraint system in a way where member
reference is going to be defined in terms of its use,
which makes it seem like parameters match arguments
exactly. Such helps to produce solutions and diagnose
failures related to missing members precisely.
These changes would be further extended to diagnose use
of unavailable members and other structural member failures.
Resolves: rdar://problem/34583132
Resolves: rdar://problem/36989788
Resolved: rdar://problem/39586166
Resolves: rdar://problem/40537782
Resolves: rdar://problem/46211109
In light of the invocation limits placed on space subtraction, this grossly incorrect check is being dropped.
Resolves a source of miscompiles in mostly machine-generated code
including SR-6652 and SR-6316.
Previously if a declaration had both a Type and a TypeRepr available,
we would only check the access of the TypeRepr. However, this is
incomplete when the type is partially inferred, as in
public var inferredGenericParameters: Optional = PrivateStruct()
The new algorithm is to the Type first, then:
- if the Type is okay, move on to check the TypeRepr
- if the Type is not okay and we're in pre-Swift-5 mode, check the
TypeRepr, and if /that's/ okay downgrade the whole thing to a
warning.
Unfortunately, we can't /just/ check the Type in the "good" case,
because we don't always properly preserve sugar when going from a
TypeRepr that represents a typealias to the corresponding Type, and we
want to be able to fix those cases in the future. So we have to check
both.
This patch mainly consolidates the functions used to check accessors vs.
other decls, and makes sure we check setter access as well as regular
decl access.
rdar://45217648
Previously, members of protocols that were not protocol requirements,
like accessors and typealiases, did not inherit @usableFromInline from
the parent protocol. Change this so they do.
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.
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
Swift versions < 5 allowed argument passed to @autoclosure parameter
to be @autoclosure function type, we need to make sure that such
behavior is preserved.
...when the protocol and the conforming type are not both public but
are both public-or-usableFromInline. It's possible to write inlinable
functions that depend on these types:
public protocol HasAssoc {
associatedtype Assoc
}
public func getAssoc<T: HasAssoc>(_: T) -> T.Assoc
@usableFromInline struct Impl: HasAssoc {
@usableFromInline typealias Assoc = Int
}
@inlinable func test() {
let x: Int = getAssoc(Impl())
}
rdar://problem/43824052
Completely mechanical changes:
- Explicit @objc in a few places
- Some imported APIs changed
- For the mix-and-match tests, just test version 4/5 instead of 3/4
- Treat protocol requirements just like associated types in how they
inherit usable-from-inline-ness, rather than special-casing them in
the check for inlinable code.
- Enum elements are already treated this way, so we can remove a
redundant check for that.
- Finally, start enforcing that 'dynamic' declarations need to be
'@usableFromInline' to be used in inlinable functions...in Swift 5
mode or resilient code. I didn't even add a warning in Swift 4/4.2
because it was illegal to use '@usableFromInline' on a 'dynamic'
declaration in Swift 4.2. (Oops.)
It actually /does/ make sense to enforce the usable-from-inline rules
on dynamic declarations, but that would break source compatibility at
this point. Just allow '@usableFromInline' to be written on 'dynamic'
declarations, so that it'll be compatible with Swift 5.
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.
