- NominalTypeDecl::computeInterfaceType() crash when parent decl
has error type
- createMaterializeForSetPrototype() crash when parent decl
has error type
- Crashes in ConformanceChecker when decl has error type
Fixes <rdar://problem/21583601>.
Swift SVN r29912
Archetypes either need to be a root, which corresponds to a type
parameter, or need to be parented by another archetype. When the
representative of an equivalence class of potential archetypes has a
parent, but that parent has been made equivalent to some concrete type
via a same-type constraint, choose a different potential archetype as
the "anchor", i.e., one that has no concrete types in its parent
chain. Fixes rdar://problem/21625478 and the canonical example in
rdar://problem/17619740.
Swift SVN r29898
... I have no idea why we were foolishly mapping such things to their
parent type, which made no sense whatsoever. Fixes
rdar://problem/21621421.
Swift SVN r29882
All archetypes from outer scopes are fixed (as a lame implementation
restriction), so same-type constraints that involve archetypes from
outer scopres should treat the archetypes from outer scopes as the
representative. Do so, and start eliminating the notion of a "primary"
archetype that was preventing this fix from occurring earlier, so that
"all archetypes" and the set of requirements generated from the
archetype builder still line up.
Fixes rdar://problem/19519590.
Swift SVN r29869
ExtensibleCollectionType's operations can all be represented by the
primitive range replacement operation, so fold it into
RangeReplaceableCollectionType.
In addition, provide default implementations of
RangeReplaceableCollectionType's methods.
- New tests added for combinations of (static, generic) calls and
(default, custom) implementations.
- Mark free Swift functions as unavailable with a message to direct the
developer to the protocol methods.
- Mark ExtensibleCollectionType as available with a message added to
direct the developer to the right protocol.
rdar://problem/18220295
Swift SVN r29857
expressions. Broadening from callexpr to apply expr (picking up operators) improves
several diagnostics in the testsuite, and is important to avoid regressions from an
upcoming patch.
Swift SVN r29821
We were doing piecemeal checking of the requirements of specific
associated type bindings, but such checking is incomplete: superclass
constraints and, although currently inexpressible, same-type
constraints are not validated by these early checks, so this is more
correct and more robust.
Swift SVN r29808
Previously, we were simply walking over the requirements of each of
the associated types, which meant that we weren't considering
same-type constraints. Also cleans up the diagnostics a little bit and
eliminates some extra computation whose results were getting thrown
away.
Swift SVN r29793
This approach should help us massively reduce the amount of code it
takes to verify that the architecture of our protocols works as
expected. Pair-programmed with Dmitri Hrybenko.
Swift SVN r29752
Eliminates _CollectionDefaultsType and _CollectionGeneratorDefaultsType
and creates sanity that should allow us to Protocol Extension-ize the
lazy operations, which have been blocked on inscrutable errors due in
part to the existing complexity.
Note: names beginning with "_prext_" are intended to be public after API
review and removal of the "_prext_" prefix.
Swift SVN r29689
DeferCleanup pushes a new temporary cleanup to catch non-local returns
from the defer block, so we have to use stable iterators while emitting
cleanups.
There's no good deterministic test case for this -- it would manifest
as memory corruption if the underlying storage of the DiverseStack
grew beyond the inline storage. Add a reduced version of the original
user-reported test case that triggers it reliably -- I had a hard time
coming up with anything simpler.
Fixes <rdar://problem/21437203>.
Swift SVN r29658
We didn't have any tests exercising SubstToOrigComponent and in
fact it was broken. Fix emitInOut() to remove a level of inout
from the origParam abstraction pattern and add some tests.
Fixes <rdar://problem/20985062>.
Swift SVN r29644
struct ReverseIndex<Base : BidirectionalIndexType> { ... }
struct ReverseRandomAccessIndex<Base : RandomAccessIndexType> { ... }
// Renamed from `BidirectionalReverseView`.
struct ReverseCollection<Base : CollectionType where T.Index : BidirectionalIndexType> { ... }
// Renamed from `RandomAccessReverseView`.
struct ReverseRandomAccessCollection<Base : CollectionType where T.Index : RandomAccessIndexType> { ... }
Also fixed a bug (found by the new tests I added in this commit) in
LazyRandomAccessCollection.reverse(), which mistakenly returned a bidirectional
reversed collection.
Part of rdar://21429126
Swift SVN r29634
We diagnose usage of invalid existential types but we might still
try to compute substitutions. Just whip up an ErrorType instead.
Fixes <rdar://problem/16803384>.
Swift SVN r29567
- In name lookup, if we find a decl that is already being type checked
(which only occurs on illegal code) just assume it is acceptable instead
of blowing up with an assertion checking access control that hasn't been
evaluated yet.
- In checkInheritanceClause, make sure that the we mark the decl being
resolved as being type checked when resolving the types involved. That way,
cyclic references are detected as invalid, instead of causing assertions and
other explosions.
This fixes some compiler crashers.
Swift SVN r29538
init()'s implicitly evaluate the initial values for properties, and we aren't modeling
that correctly in the AST. This prevented the closure checker from noticing these
accesses, leading to SILGen crashing later. In the absence of proper AST modeling of
this, add special case handling for them.
Swift SVN r29508
lvalues when compiling list of partial-match overloads in diagnosis.
(This is a reapplication of commits r29462 and r29469.)
Also, fix the following tests:
stdlib/FixedPointDiagnostics.swift.gyb
stdlib/NumericDiagnostics.swift.gyb
<rdar://problem/17875634> can't append to array of tuples
Swift SVN r29493
Previously the placement of the OpenExistentialExpr was determined
entirely from the natural argument count of the function.
There was a hack to add any missing OpenExistentialExprs at the top
level, but this didn't work if the method had a Self return value
and there were intermediate expressions, eg, if someMethod has a
Self return, foo(anExistential.someMethod) would generate a
diagnostic about open existentials.
Change ExprRewriter to use a new existential placement algorithm
that instead walks up the expression stack to determine the outermost
function application of an existential base, and insert the
OpenExistentialExpr there.
Progress on <rdar://problem/21289579>.
Swift SVN r29448
