For Dictionary, that's a (KeyType, ValueType) pair. For Set, that's just
the set element type. This is more consistent with the removeAtIndex on
RangeReplaceableCollectionType (which Dictionary and Set don't conform to).
rdar://problem/20299881
Swift SVN r30696
This reverts revision r30688. The patch needs more work, because it flags a
valid case as circular, see r15054, "Relax restriction on indirectly-self-
recursive protocol conformances. (rdar://problem/16306715)".
Swift SVN r30690
- When we walk up through parent types of 'this', we also have to walk up
the parent contexts of 'gpContext', otherwise an assertion fires.
- getSuperclass() needs to map generic type parameters of the parent
type even if the superclass is not generic.
Swift SVN r30676
Validating the argument type might validate the enum decl in malformed (or
maybe even some valid?) code. We would call computeTwice() in this case,
leading to a crash.
Also clean up some test cases.
Swift SVN r30673
1. We have complex logic in stdlib/public/core/FixedPoint.swift.gyb that emits
or hides certain initializers on integer types based on the bit width
combination. We check that those APIs are indeed present or absent in cases we
expect.
All of [U]Int{8,16,32,64,} initializers, labelled and unlabelled.
(swift) UInt16(-10 as Int32)
<REPL Input>:1:1: error: integer overflows when converted from 'Int32' to 'UInt16'
UInt16(-10 as Int32)
(swift) UInt16(truncatingBitPattern: -10 as Int32)
// r3 : UInt16 = 65526
(swift) UInt16(truncatingBitPattern: -10 as Int16)
<REPL Input>:1:1: error: cannot invoke initializer for type 'UInt16' with an argument list of type '(truncatingBitPattern: Int16)'
UInt16(truncatingBitPattern: -10 as Int16)
<REPL Input>:1:1: note: overloads for 'UInt16' exist with these partially matching parameter lists: (Int16), (bitPattern: Int16)
A slight change in the type combination dramatically changes the available
overload set. You can’t check this with one or two tests and be confident that
every source/destination combination is correct.
2. We check that the APIs above are present or absent regardless of the target
platform so that the code is portable (for example, because Int64 -> Int is a
truncating operation on at least one platform, the corresponding “truncating”
initializer is available for portability on 64-bit platforms, even though it is
not actually truncating there.)
3. We rely on ambiguity in the overload set of “+“ and “-“ for certain
combinations of arguments to disallow mixed-sign arithmetic. Again, these
ambiguities rely on a tricky combination of protocols, associated types, the
way those associated types are defined by our integer types, and overload
resolution rules in the type checker.
4. The test also checks migration facilities for Word and UWord.
Swift SVN r30655
The protocol Self parameter is the last generic parameter in the signature,
not the first. While we don't allow protocols nested inside generic classes,
we would still crash in member type lookup from this.
Fixes <rdar://problem/21287703>.
Swift SVN r30635
When validateGenericFuncSignature() returns true, finalizeGenericParamList()
is never called. Name lookup, via PartialGenericTypeToArchetypeResolver would
return a dependent member type of the generic type parameter type, not an
archetype as expected in this case. This would later on lead to a crash in
ReplaceDependentTypes if the function body contained a reference to such a
member type.
Fix this by marking the GenericTypeParamDecls as invalid in this case, and
returning an ErrorType from PartialGenericTypeToArchetypeResolver if given
an invalid GenericTypeParamDecl.
While we're at it, there was an unused isInvalid local variable in
TypeCheckDecl::visitFuncDecl(). It was written to but never read. Replace
the writes with calls to setInvalid().
Fixes <rdar://problem/19620340>.
Swift SVN r30632
An index of a FlattenCollection is composed of two: an index to the
current chunk and an index within that chunk. So you take the
startIndex, and advance it to the second chunk; call the result idx1.
You take startIndex again, and advance it the same number of steps; call
the result idx2:
let idx1 = flatMapCollection.startIndex.advancedBy(10)
let idx2 = flatMapCollection.startIndex.advancedBy(10)
idx1 and idx2 have to compare equal according to collection and index
axioms. But this can't be cheaply implemented. Every index contains an
index into the inner collection. So indices into two collections with
the same elements have to compare equal even though the collections
don't have any common history, they were merely created using the same
sequence of steps.
What currently happens is that you get random results depending on the
underlying collection kind.
rdar://21989896
Swift SVN r30617
FlattenCollection used to evaluate the closure three times per element.
That's acceptable from the technical standpoint, given its lazy
semantics, but not acceptable in practice. This commit fixes it to only
evaluate it two times when it is converted into an array.
This commit also improves tests. The new checks used to fail before the
standard library was fixed.
But there are larger issues with FlattenCollection -- it does not model
CollectionType properly. See next commit.
Swift SVN r30616
These types are leftovers from the early pre-1.0 times when Int and UInt
were always 64-bit on all platforms. They serve no useful purpose
today. Int and UInt are defined to be word-sized and should be used
instead.
rdar://18693488
Swift SVN r30564
These tests trigger a bug in a lazy flatMap() that I will fix in a later
commit, but I want to commit tests separately to show that they pass
with the eager flatMap().
Swift SVN r30559
Otherwise the verifier can crash because hasType() returns true but
getType() gives us a MetatypeType that hits a null pointer in
desugaring.
The computeType() calls appear in a few too many places for my liking;
would be nice to clean this up further or replace everything with
interface types one day.
Fixes <rdar://problem/19606899>.
Swift SVN r30388
This changes the behavior to match NominalTypeDecls, which don't have a type
until everything is set up either. In a few places we construct TypeAliasDecls
from known types directly, and we have to call computeType().
Fixes <rdar://problem/19534837>.
Swift SVN r30386
rdar://problem/21663830
Add the following new requirements to SequenceType with default implementations:
- dropFirst(n)
- dropLast(n)
- prefix(n)
- suffix(n)
- split(n)
In addition, provide specialized default implementations of these for CollectionTypes with forward, bidirectional, and random-access Index types where possible.
Add the following new requirements to CollectionType with default implementations:
- prefixThrough(n)
- prefixUpTo(n)
- suffixFrom(n)
- split() // isSeparator closure
Add the following convenience APIs:
- dropFirst() -> calls dropFirst(1)
- dropLast() -> calls dropLast(1)
Add a tentative underscored API:
- split() // takes Equatable separator.
Some APIs have undefined behavior when creating slices where the endpoints go beyond the bounds of the underlying collection. This will be fixed later by trapping creation of slices with invalid indices (rdar://problem/21822657).
Swift SVN r30371
