Otherwise, the length of the sequence is in principle lost. If you know
you have a sequence of less than 100 elements, you still want to know
exactly how many elements you initialized from it.
Swift SVN r30104
The way we pass and compose source locations, messages, etc. needs to be
brought under control before too many more tests get written. This is
the first step.
Swift SVN r29928
Remove these standard library types in favor of (T) -> () closures.
It was originally believed that generic optimizations would make these
types profitable, however:
// FIXME: Insert benchmarks here.
rdar://problem/21663799
Swift SVN r29927
Compiler output at least up to serialization should be deterministic at this point,
at least when not taking SIL into account. This /should/ mean that changing a
function body should not affect the final built swiftmodule, which means downstream
targets don't need to be rebuilt. Leaving the previous swiftmodule output in place
signals that.
A while back I put in a push to get all the non-determinism out of type checking,
importing, and serialization itself; it looks like we've finally made it. Let's keep
it that way!
rdar://problem/20539158 and others
Swift SVN r29923
Add a shared buffer to every range replaceable mutable collection to
track logical mutations, and invalidate all indices on every mutation.
Swift SVN r29917
For now, just update NameLookup's FindLocalVal to use a
VisibleDeclConsumer just like lookupVisibleDecl().
A subsequent patch will continue removing duplicated code
now that this is place.
This fixes compiler crashers where we were not handling
declarations with duplicate names (which of course is an
error, diagnosed elsewhere).
Swift SVN r29913
- 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
