For explicit abstract protocol floating requirement sources, get the source location from the protocol requirement rather than delegating to the parent `RequirementSource`.
Use the declaration-based name lookup facilities to re-implement
ProtocolDecl::getInheritedProtocols(), rather than dynamically selecting
between the requirement signature and the inherited types. This reduces
dependencies for this computation down to basic name lookup (no semantic
analysis) and gives us a stable result.
Whenever we visit a declaration via the DeclChecker, add it to the
list of declarations to finalize. This makes sure that we can centralize
the notion of “finalize for SILGen” and that it will be called for
everything in the source file being processed.
These will never work properly because of phase ordering issues with
the current declaration checker design. Since we can always express
the same thing with the protocol inheritance clause instead, just
diagnose this as an error instead of trying to hack around it.
Fixes <rdar://problem/38077232>, <https://bugs.swift.org/browse/SR-5581>.
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>.
Otherwise, the initializer won't be inherited properly onto a
subclass, resulting in the base class being allocated instead of the
subclass when using Sub.init(from:).
https://bugs.swift.org/browse/SR-8083
Allow witnesses to protocols in a copyable context to elide explicit
ownership conventions. This allows clients like the standard library to
standardize on one ownership convention without an ABI or API breaking
change in 3rd party code.
In the future, moveonly contexts must disallow this default behavior
else the witness thunks could silently transfer ownership.
rdar://40774922
protocol P {
__consuming func implicit(x: __shared String)
__consuming func explicit(x: __owned String)
__consuming func mismatch(x: __shared String)
}
class C : P {
// C.implicit(x:) takes self and x '@guaranteed' thru the witness thunk
func implicit(x: String) {}
// C.explicit(x:) takes self and x @owned with no convention changes
__consuming func explicit(x: __owned String) {}
// Would inherit __consuming, but x has been spelled __owned so the requirement match fails.
func mismatch(x: __owned String) {}
}
Implement TypeChecker::resolveInheritedProtocols() in terms of
"getInheritedType()" queries, instead.
[Sema] Put back resolveInheritedProtocols().
We're still depending on it to update state in some cases.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
'private' properties can't be accessed in extensions in Swift 3, so synthesizing
a conformance that reads from such things is going to be incorrect in an
extension.
This works for all protocols except for Decodable on non-final classes, because
the init requirement has to be 'required' and thus in the type's declaration.
Fixes most of https://bugs.swift.org/browse/SR-6803.
We don't allow things like
extension Type: P where Param: P {}
extension Type: P where Param: Q {}
or
extension Type: P where Param == Int {}
extension Type: P where Param == Float {}
or
extension Type: P where Param: P {}
extension Type: P where Param == SomethingThatIsntP {}
and the default error message "redundant conformance" message doesn't convey
this very well.
Fixes rdar://problem/36262409.
Previously, we just took the first match so:
1. We would try to emit a metatype lookup of the property but had prepared an instance lookup.
2. Could get the wrong type if the static/instance property had different types.
rdar://39669212
By formalizing ReferenceOwnership as a diagnostic argument kind, we get
less boilerplate, better type safety, better output consistency, and
last but not least: future proofing.
Since 'private' means "limit to the enclosing scope (and extensions
thereof)", putting it on a member means that the member can't be
accessed everywhere the type might show up. That's normally a good
thing, but it's not the desired effect for synthesized members used
for derived conformances, and when it comes to class initializers this
actually violates AST invariants.
rdar://problem/39478298
