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
Introduce a new locator kind for argument/parameter comparisons that
tracks both the argument and the parameter, which we will eventually
use in diagnostics more regularly. For now, this helps us smooth over
scalar-to-tuple/tuple-to-tuple/tuple-to-scalar nonsense when dealing
with calls.
Fix a pile of fallout from this change.
Swift SVN r17648
Add a third branch to the constraint system for '&x' expressions that allows conversion from an lvalue to a type via an additional writeback step:
- Add an LValueConversionExpr node that converts from @lvalue T to @lvalue U, given a pair of functions that convert T -> U and U -> T, to represent the writeback temporary.
- Allow conversion in an inout expression from @lvalue T to a type U that has the following members:
static func __writeback_conversion(Builtin.RawPointer, T.Type) -> U
static func __writeback_conversion_get(T) -> V
static func __writeback_conversion_set(V) -> T
which builds a solution that produces an LValueConversion from the get/set pair before passing the pointer to the writeback temporary off to the conversion function.
Swift SVN r15764
We'll need types to be convertible from multiple kinds of inouts, which currently can't be represented with protocol conformance since we only allow one protocol conformance per type per protocol. Instead just look for a magic "__inout_conversion" static method in the type; this is lame but easy, and inout conversions shouldn't be available outside of the stdlib anyway.
Swift SVN r15599
While diagnosing the cause of a constraint system failure, being able to ignore some failures but not others allows us to produce slightly better error messages in some cases. This is in support of JoeG's current work.
Swift SVN r15560
a function conversion to be bad.
This encourages the type-checker to place conversions within
closures rather than outside; the test case here crashed in
SIL verification because of that. (Yes, that means that there's
an underlying problem still when the function conversion is
required; that's tracked by rdar://15875305.) But in general,
function conversions are likely to be expensive, and it's good
to avoid them when possible.
The setup work to add SK_FunctionConversion was accidentally
committed as part of r12813.
Swift SVN r12839
