upcasts."
Reinstate "Restrict the array-bridged conversion to non-verbatim
bridging."
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Fix T[].bridgeFromObjectiveC"
Reinstate "[stdlib] Move _arrayBridgedDownCast to Foundation"
Reinstate "Replace "can" with "cannot" in a message."
Reinstate "Implement support for non-verbatim T[] -> AnyObject[]
upcasts."
This reinstates commit r18291.
This reinstates commit r18290.
This reinstates commit r18288.
This reinstates commit r18287.
This reinstates commit r18286.
This reinstates commit r18293.
This reinstates commit r18283.
John fixed the issue in r18294.
Swift SVN r18299
Revert "Restrict the array-bridged conversion to non-verbatim bridging."
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Fix T[].bridgeFromObjectiveC"
Revert "[stdlib] Move _arrayBridgedDownCast to Foundation"
Revert "Replace "can" with "cannot" in a message."
Revert "Implement support for non-verbatim T[] -> AnyObject[] upcasts."
This reverts commit r18291.
This reverts commit r18290.
This reverts commit r18288.
This reverts commit r18287.
This reverts commit r18286.
This reverts commit r18293.
This reverts commit r18283.
Sorry for the number of reverts, but I needed to do this many to get a clean
revert to r18283.
Swift SVN r18296
Previously, we were relying on overly-general subtyping to determine
when we could perform an array upcast, which pushed some non-verbatim
bridging through that path. Instead, restrict array upcasts to classes
and ObjC existentials, and use bridging casts for the other cases.
Swift SVN r18291
One of my recent type-checker changes starting passing all array
upcasts, including "bridged" ones like String[] -> AnyObject[],
through the library entry point _arrayUpCast, which is only meant for
class/ObjC existential types that are bridged verbatim.
Fixes part of <rdar://problem/16952238>; more cleanup to follow.
Swift SVN r18283
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
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
- Continue adding support for checked downcasts of array types (rdar://problem/16535104)
- Fix non-bridged array conversions post-r17868
- Fix rdar://problem/16773693
- Add tests for NSArray coercions to and from Array<T>
Swift SVN r17957
Use protocol conformance checks whenever we want to determine whether
a value type is bridged to an Objective-C class, which is simpler and
more robust. Clean up some of the type checker code around bridging,
using TypeBase::isEqual() to compare types and looking through type
sugar more regularly.
As part of this, move Array's conformance to
_ConditionallyBridgedToObjectiveC into the Foundation overlay. This
lets us use NSArray as the bridged type (which is clearer than using
CocoaArray), and follows what we're doing for dictionary bridging.
As part of this, move Array's bridged-to-
Swift SVN r17868
While this should be a pointless performance tweak along a path where
we don't care about performance, it actually matters because we
occasionally end up copying SmallStrings or std::strings, then taking
StringRefs to the copies and holding on to them. This was manifesting
as occasional corruption in keyword-argument diagnostics.
Swift SVN r17811
- Mine conjunction constraints for constraint failure data. (rdar://problem/16833763)
- Rather than crash, add a diagnostic to signify a missing user constraint. (rdar://problem/16747055) I don't have a deterministic repro for this to include as a test, but users hit it from time to time, I'd like to address this issue holistically, and we're hoping that the new diagnostic will help us collect isolated repros.
- As promised, remove the temporary "compiler_submit_version" build configuration predicate in time for WWDC. (rdar://problem/16380797)
Swift SVN r17705
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
I no longer have any tests that trigger this behavior (they've been
fixed), but it's the right fallback: otherwise, we end up applying the
same fixes when trying to create diagnostics, then emit no diagnostics
because we've "succeeded".
Swift SVN r17425
Subscript declarations were still encoding the names of index
variables in the subscript type, which unintentionally made them
keyword arguments. Bring subscript declarations into the modern day,
using compound names to encode the subscript argument names, which
provides consistency for the keyword-argument world
<rdar://problem/14462349>. Note that arguments in subscripts default
to not being keyword arguments, which seems like the right default.
We now get keyword arguments for subscripts, so one can overload
subscripts on the names of the indices, and distinguish at the call
site. Under -strict-keyword-arguments, we require strictness here as well.
The IRGen/IDE/SILGen test updates are because the mangling of common
subscripts changed from accidentally having keyword arguments to not
having keyword arguments.
Swift SVN r17393
Implement a completely new path for matching up an argument tuple to a
parameter tuple, which handles the specific rules we want for
calls. The rules are:
- The keyword arguments at the call site must match those of the
declaration; one cannot omit a keyword argument if the declaration
requires it, nor can one provide a keyword argument if the
declaration doesn't have one.
- Arguments must be passed in order, except that arguments for
parameters with defaults can be re-ordered among themselves (we
can't test all of this because neither constraint application nor
the AST can express these).
QoI is extremely important in this area, and this change improves the
situation considerably. We now provide good diagnostics for several
important cases, with Fix-Its to clean up the code:
- Missing keyword arguments:
t.swift:8:13: error: missing argument labels 'x:y:' in call
allkeywords1(1, 2)
^
x: y:
- Extraneous keyword arguments:
t.swift:17:12: error: extraneous argument labels 'x:y:' in call
nokeywords1(x: 1, y: 1)
^~~~ ~~~
- General confusion over keyword arguments (some missing, some
wrong, etc.):
t.swift:26:14: error: incorrect argument labels in call (have
'x:_:z:', expected '_:y:z:')
somekeywords1(x: 1, 2, z: 3)
^~~~
y:
There are still a few areas where the keyword-argument-related
diagnostics are awful, which correspond to FIXMEs in this
implementation:
- Duplicated arguments: f(x: 1, x: 2)
- Extraneous arguments: f(x: 1, y: 2, z: 3) where f takes only 2
parameters
- Missing arguments
- Arguments that are out-of-order
- Proper matching of arguments to parameters for diagnostics that
complain about type errors.
And, of course, since this has only been lightly tested, there are
undoubtedly other issues lurking.
This new checking is somewhat disjoint from what constraint
application can handle, so we can type-check some things that will
then fail catastrophically at constraint application time. That work
is still to come, as is the AST work to actually represent everything
we intend to allow.
This is part of <rdar://problem/14462349>.
Swift SVN r17341
We want to eliminate single-element tuples, but for now we need to
keep them from crashing the compiler. Fixes
<rdar://problem/16795899>.
Swift SVN r17286
Another baby step toward <rdar://problem/14462349>, made even more
tepid by the fact that I've quarantined this behind a new flag,
-strict-keyword-arguments. Enforcing this breaks a lot of code, so I'd
like to bring up the new model on the side (with good diagnostics that
include Fix-Its) before trolling through the entire standard library
and testsuite to fix violations of these new rules.
Swift SVN r17143
This is the simplest case to test the infrastructure for
adding/removing/fixing keyword arguments at the call site that don't
line up with the keyword arguments in a declaration. Baby steps toward
<rdar://problem/14462349>.
Swift SVN r17136
As part of this, use tail allocation to reduce the memory footprint of
TupleExprs. Use factory methods to make it easier to construct.
I'll be using this information in a follow-on patch. SourceKit
probably wants it as well.
Swift SVN r17129
Make ObjC method partial applications go through a native-to-foreign thunk so that we properly handle bridging conversions in the resulting function value. Partial applications through dynamic lookup are still broken because they apparently go through a different path.
Swift SVN r17108
double-quoted string literals that contain a single extended grapheme cluster
SEGCL by default infer type String, but you can ask to infer Character
for them.
Single quoted literals continue to infer Character.
Actual extended grapheme cluster segmentation is not implemented yet,
<rdar://problem/16755123> Implement extended grapheme cluster
segmentation in libSwiftBasic
This is part of
<rdar://problem/16363872> Remove single quoted characters
Swift SVN r17034
Building on previous work, this allows us to properly handle things like Int?() and Int[]().
Of course doing this exposed that TypeExpr was not correct in lots of ways, so this also:
- Revamps TypeExpr processing to carry a decl in the TypeLoc instead of
carrying a Type. This allows us to correctly handle more complex generics case.
- Enhances CSGen to properly open generic types so we can infer generic type parameters from
context.
Swift SVN r17019
- Change astdumper to print the typerepr in the more canonical syntax.
- Remove bogus logic from CSApply that was preventing us from rewriting
TypeExprs properly
- Teach CSGen to handle unbound generics correctly (thanks to Doug for the help on this)
Swift SVN r17007
Fixes <rdar://problem/15042686>, i.e.,
t.swift:3:7: error: call to non-function of type 'Int'; did you mean
to leave off the '()'?
i = i()
^~~
Swift SVN r16950
Example:
test/Constraints/fixes.swift:54:9: error: value of optional type 'B?'
not unwrapped; did you mean to use '!' or '?'?
b = a as B
^
!
Swift SVN r16938
