TODO:
- Select the KeyPath subclass corresponding to the write capability of the key path components
- Figure out an issue with unresolved solutions being chosen with contextually-typed keypaths
- Diagnostic QoI
Previously we would check TMF_UnwrappingOptional flag, which does not
stick with the constraint, so it would not always persist. Now, add a
new OptionalPayload locator element, which is more correct.
Fixes <rdar://problem/30429709>.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
Simplify and improve the checking of @objc names when matching a
witness to a requirement in the @objc protocol. First, don't use
@objc-ness as part of the initial screening to determine whether a
witness potentially matches an @objc requirement: we will only reject
a potential witness when the potential witness has an explicit
"@nonobjc" attribute on it. Otherwise, the presence of @objc and the
corresponding Objective-C name is checked only after selecting a
candidate. This more closely mirrors what we do for override checking,
where we match based on the Swift names (first) and validate
@objc'ness afterward. It is also a stepping stone to inferring
@objc'ness and @objc names from protocol conformances.
Second, when emitting a diagnostic about a missing or incorrect @objc
annotation, make sure the Fix-It gets the @objc name right: this might
mean adding the Objective-C name along with @objc (e.g.,
"@objc(fooWithString:bar:)"), adding the name to an
unadorned-but-explicit "@objc" attribute, or fixing the name of an
@objc attribute (e.g., "@objc(foo:bar:)" becomes
@objc(fooWithString:bar:)"). Make this diagnostic an error, rather
than a note on a generic "does not conform" diagnostic, so it's much
easier to see the diagnostic and apply the Fix-It.
Third, when emitting the warning about a non-@objc near-match for an
optional @objc requirement, provide two Fix-Its: one that adds the
appropriate @objc annotation (per the paragraph above), and one that
adds @nonobjc to silence the warning.
Part of the QoI improvements for conformances to @objc protocols,
rdar://problem/25159872.
The two types are nearly identical, and Fixnum is only in the Swift branches of LLVM,
not in mainline LLVM.
I do want to add ++ to PointerEmbeddedInt and fix some of this ugliness, but that'll
have to go through LLVM review, so it might take a bit.
Introduce a new "OpenedGeneric" locator for when openGeneric opens a generic
decl into a plethora of constraints, and use this in CSDiags to distinguish
whether a constraint refers to an Expr as a whole or an "aspect" of the constraint.
Use that information in FailureDiagnosis::diagnoseGeneralConversionFailure
to know whether (as a fallback) we can correctly re-typecheck an entire expr
to obtain a missing type. If we are talking about an aspect of the expr, then
this clearly won't work.
The upshot of this is that where we previously compiled the testcase in 22519983
to:
y.swift:31:9: error: type '(inout _) -> Bool' does not conform to protocol 'RawRepresentable'
let a = safeAssign
^
we now produce the somewhat more useful:
y.swift:31:9: error: argument for generic parameter 'T' could not be inferred
let a = safeAssign
^
y.swift:27:6: note: in call to function 'safeAssign'
func safeAssign<T: RawRepresentable>(inout lhs: T) -> Bool {
^
Swift SVN r31620
get the same wording, fixing <rdar://problem/21964599> Different diagnostics for the same issue
While I'm in the area, remove some dead code.
Swift SVN r30713
If we end up trying to form a substitution where the replacement type
is an existential and there is a conformance to a non-@objc protocol
(i.e., a conformance where a witness table is required), complain in
Sema rather than crashing in IRGen. Fixes rdar://problem/21087341, but
the existential/generic interaction is still quite broken.
Swift SVN r29133
Previously, we were reconstructing this mapping from the "full" opened
type produced by declaration references. However, when dealing with
same-type constraints between associated types and type parameters, we
could end up with an incomplete mapping, which let archetypes slip
through. Most of the churn here is sorting out the locators we need to
use to find the opened-type information. Fixes rdar://problem/18208283
and at least 3 dupes of it that I've found so far.
Swift SVN r25375
The previous approach -- which attempted to put an llvm::Fixnum<52> into an
llvm::PointerUnion -- failed to compile for 32-bit platforms. This approach now
explicitly uses 62 bits of a uint64_t for storing either an ArchetypeType * or
an llvm::Fixnum<62>, using the remaining 2 bits to store what kind of value is
in storage.
This fixes <rdar://problem/19283881>.
Swift SVN r24084
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
FixNum.h and BCRecordLayout.h will move down into LLVM, APINotes
will move into Clang. Get the namespaces right before we start to move
files around.
Swift SVN r22218
Locators that refer to opened type parameters now carry information
about the source location where we needed to open the type, so that
(for example) we can trace an opened type parameter back to the
location it was opened. As part of this, eliminate the "rootExpr"
fallback, because we're threading constraint locators everywhere.
This is infrastructural, and should be NFC.
Swift SVN r21919
checked cast expression.
We don't actually *use* that path for anything right now,
because we basically re-check the cast from scratch after
constraint application. This is nonetheless necessary to
avoid collisions with constraints which might be located
on the result, such as would arise in an initialization
context.
In particular, this patch fixes a crash arising when both
the operand and the result of a coercion require a
user-defined conversion. Test to follow.
Swift SVN r18386
We use KindAndValue storage to encode an argument index as well as other fields. The index argument overflows with long array literals.
KindAndValue is defined like this: typedef Fixnum<29> KindAndValueStorage;
We encode the three values in 'value' with a 16 bit offset for the first field and 8 bit offset for the second field . 29 - 16 - 8 = 5 bits. This means that we can only support 2^5 = 32 arguments.
Swift SVN r17815
