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.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
The removal of these operator declarations caused a source
compatibility break, because some Swift code is defining prefix or
postfix ++/-- functions without defining the ++ or --
operators. Reinstate the operator declarations in the standard
library... but not any of the functions.
Fixes rdar://problem/43258773.
This patch adds warning for redundant access-level modifiers
used in an extension. It also refines the diagnostics of
access_control_ext_member_more issues, in case the fixit
could suggest redundant modifiers.
Resolves: SR-8453.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
When a `fileprivate` method is declared in a `private`
extension, a warning is raised since access level
`fileprivate` is literally higher than `private`.
This is not appropriate because extensions are top level
declarations, for which `private` and `fileprivate` are
equivalent. This patch stops such warnings.
Resolves: SR-8306.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
Recent work to improve checking for forward references to local types
(https://github.com/apple/swift/pull/16967) started rejecting code
that referred to a local type before it is defined. Swift previously
accepted such code, because local types can’t capture anyway, so allow
it again… for now.
As a separate action item, I’d like to revisit the language design
here, because it’s somewhat surprising when we can vs. cannot
forward-reference local declarations, and the rules differ from
those of top-level code in scripts *and* top-level code for non-scripts.
Fixes rdar://problem/41659447
This is fix for a source compat regression from:
commit 790625ab5b
Author: Doug Gregor <dgregor@apple.com>
Date: Mon Mar 19 15:29:32 2018 -0700
Allow a witness's noescape parameter to match a requirement's escaping parameter
The regression is not severe but its easy enough to fix.
With the above change, it was possible for an optional requirement that did
not have a witness in Swift 4.1 to pick up a witness in Swift 4.2, because
the escaping/noescape mismatch prevented it from being considered in Swift 4.1.
If the new witness was not sufficiently visible, this caused a source
compatibility regression.
Work around this by discarding the witness if its not sufficiently
visible. In -swift-version 5, the hack expires, and we revert to the
stricter, more consistent behavior.
Fixes <rdar://problem/39614880>.
Without this, the compiler ended up complaining about missing cases
that can't actually occur, like `Optional<Never>.some(_)`. This was a
regression from Swift 4.1.
https://bugs.swift.org/browse/SR-8125
