When two protocol requirements would otherwise be considered
"identical", take the one from the most-refined protocol. This whole
hack *should* go away when we properly handle overriding for protocol
requirements, but for now it fixes rdar://problem/21322215.
Swift SVN r29785
We might be looking at a protocol requirement, which conforms to a
protocol but has a null conformance. Also, don't bother looking at
completeness: it doesn't matter. Fixes rdar://problem/20608438.
Swift SVN r27860
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Compare the generic signatures so that we get appropriate partial
ordering among constrained extensions, extensions of inherited
protocols, etc. Finishes rdar://problem/20335936.
Swift SVN r26726
Implement simplistic partial ordering rules for members of protocol
extensions. Specifically:
- A member of a concrete type is more specialized than a member of a
protocol extension
- A member of a protocol extension of P1 is more specialized than a
member of a protocol extension of P2 if P1 inherits from P2
This achieves most of what rdar://problem/20335936 covers, but does
not yet handle ordering between constrained protocol extensions.
Swift SVN r26723
let x: Int? = 4 as Int // okay
let f: (Int) -> Void = { (x: Int?) -> Void in println(x) } // error!
As part of this, remove an invalid "protection" of value-to-optional
conversions that involve T? -> T??. Unfortunately, this results in an
ambiguity in the following code:
var z: Int?
z = z ?? 42
Both of our overloads for ?? here require one value-to-optional conversion,
and the overload preference isn't conclusive. (Turns out (T?, T) and
(U?, U?) can be unified as T=U or as T=U?.) The best thing to do would be
to take our solved T=Int binding into account, but the type checker isn't
set up to do that at the moment.
After talking to JoeP, I ended up just hardcoding a preference against
the (T?, T?) -> T? overload of ??. This is only acceptable because both
overloads have the same result, and I'll be filing another Radar to
remove this hack in the future.
Part of rdar://problem/19600325
Swift SVN r25045
The archetype opener only needs to perform basic substitutions; let it
do so, avoiding the creation of a pile of type variables that simply
get immediately bound.
Swift SVN r24399
Specifically, it's not when
- the conformance is being used within a function body (test included)
- the conformance is being used for or within a private type (test included)
- the conformance is being used to generate a diagnostic string
We're still a bit imprecise in some places (checking ObjC bridging), but
in general this means less of an issue for checking literals.
Swift SVN r23700
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
This is the semantic change we need to eliminate ambiguities when
introducing the new ?? overload. There is a minor regression here with
curried method references, which is covered by <rdar://problem/18006008>.
Swift SVN r21173
To facilitate the removal of the BooleanType conformance from Optional<T>, we'll first need to support
equality comparisons between the 'nil' literal and optionals with non-equatable element types.
We can accomplish this via three changes:
- New overloads for "==" and "!=" that we can resolve against non-equatable optionals
- A tweak to our overload resolution algorithm that, when all other aspects of two overloads are
considered equal, would favor the overload with a more "constrained" type parameter. This allows
us to avoid ambiguities between generic overloads that are distinct, but whose parameters do not
share a pairwise subtype relationship.
- A gross hack to favor overloads that do not require bindings to 'nil' when presented with an
otherwise ambiguous set of solutions. (Essentially, in the face of a potential ambiguity, favor solutions
that do not require bindings to _OptionalNilComparisonType over those that do.)
The third change is only necessary because we currently lack the ability to specify "negative" or
otherwise more expressive constraints, so we'll want to rethink the hack post-1.0. (I've filed
rdar://problem/17769974 to cover its removal.)
Swift SVN r20346
We still have type checker support for user-defined conversions,
because the importer still synthesizes __conversion functions for CF
<-> NS classes.
Swift SVN r19813
When we see a '.member' expression in optional context, look for the member in the optional's object type if it isn't found in Optional itself. <rdar://problem/16125392>
Swift SVN r19469
We need to admit a potential inout-to-pointer conversion even if the inout references an array, because we can have pointers to arrays. Add a short-circuit so that array-to-pointer conversions always beat inout-to-pointer conversions; both solutions could otherwise be considered valid for an UnsafePointer<Void>, and passing a pointer to the array reference rather than to the array data would be very bad.
Swift SVN r19270
Add primitive type-checker rules for pointer arguments. An UnsafePointer argument accepts:
- an UnsafePointer value of matching element type, or of any type if the argument is UnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is UnsafePointer<Void>, or
- an inout Array parameter of matching element type, or of any type if the argument is UnsafePointer<Void>.
A ConstUnsafePointer argument accepts:
- an UnsafePointer, ConstUnsafePointer, or AutoreleasingUnsafePointer value of matching element type, or of any type if the argument is ConstUnsafePointer<Void>,
- an inout parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>, or
- an inout or non-inout Array parameter of matching element type, or of any type if the argument is ConstUnsafePointer<Void>.
An AutoreleasingUnsafePointer argument accepts:
- an AutoreleasingUnsafePointer value of matching element type, or
- an inout parameter of matching element type.
This disrupts some error messages in unrelated tests, which is tracked by <rdar://problem/17380520>.
Swift SVN r19008
This makes categories of NSString, NSArray, and NSDictionary available
on String, Array, and Dictionary. Note that we only consider
categories not present in the Objective-C Foundation module, because
we want to manually map those APIs ourselves. Hence, no changes to the
NSStringAPI. Implements <rdar://problem/13653329>.
Swift SVN r18920
One difficulty in generating reasonable diagnostic data for type check failures has been the fact that many constraints had been synthesized without regard for where they were rooted in the program source. The result of this was that even though we would store failure information for specific constraints, we wouldn't emit it for lack of a source location. By making location data a non-optional component of constraints, we can begin diagnosing type check errors closer to their point of failure.
Swift SVN r18751
This is a better solution to <rdar://problem/16899681> because the
runtime magic is limited to implementing the witnesses of this
conformance.
The type checker fixes are because we can end up using unchecked
optionals in more places, via bridging, than we could before.
Swift SVN r18120
Introduce some infrastructure that allows us to speculatively apply
localized fixes to expressions during constraint solving to fix minor
typos and omissions. At present, we're able to introduce the fixes
during constraint simplification, prefer systems with fewer fixes when
there are multiple fixes, and diagnose the fixes with Fix-Its.
Actually rewriting the AST to reflect what the Fix-Its are doing is
still not handled.
As a start, introduce a fix that adds '()' if it appears to have been
forgotton, producing a diagnostic like this if it works out:
t.swift:8:3: error: function produces expected type 'B'; did you mean
to call it with '()'?
f(g)
^
()
Note that we did regress in one test case
(test/NameBinding/multi-file.swift), because that diagnostic was
getting lucky with the previous formulation.
Swift SVN r16937
...and teach the type-checker to prefer variables to functions.
This matters in Objective-C, where you may have these two members:
@property NSURL *URL;
- (void)URL:(NSURL *)url resourceDidFailLoadingWithReason:(NSString *)reason;
This doesn't happen often, but we should do the right thing when it does.
We still won't import a property named 'foo' if there is already a method
'-foo' that takes no arguments.
<rdar://problem/16383845>
Swift SVN r15963
That is, NSObject.isEqual(someObj) should call +isEqual:, not be equivalent
to someObj.isEqual, unless there's a type context that says otherwise.
<rdar://problem/16527717>
Swift SVN r15955
Change GenericFunctionType to reference a GenericSignature instead of containing its generic parameters and requirements in-line, and clean up some interface type APIs that awkwardly returned ArrayRef pairs to instead return GenericSignatures instead.
Swift SVN r13807
its basic logic in libAST, which both makes it easier to
implement and makes it possible to use in the places that
should care about it, i.e. in IR-gen and SIL-gen.
Per Doug, none of the places that were introducing
trivial-subtype constraints really needed to do so rather
than just using subtype constraints.
Swift SVN r12679
As part of this, take away the poor attempt at recovering by adding an
explicit protocol conformance. The recovery mode isn't all that useful
in a system with only explicit conformance, and it messes with
diagnostics further down the line. We can bring it back later once
we're happy with explicit conformance checking.
Swift SVN r11503
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
