All refutable patterns and function parameters marked with 'var'
is now an error.
- Using explicit 'let' keyword on function parameters causes a warning.
- Don't suggest making function parameters mutable
- Remove uses in the standard library
- Update tests
rdar://problem/23378003
The basic idea is to move the allocation of the buffer out of @_semantics("array.uninitialized") so that it can be inlined without inlining the semantics function (on high-level SIL).
This change in the stdlib also requires an adaption of the dead area elimination in DeadObjectElimination.
Otherwise it would just remove the semantics function but not the allocation and we would leak memory.
Make the following patterns illegal:
if var x = ... {
...
}
guard var x = ... else {
...
}
while var x = ... {
...
}
And provide a replacement fixit 'var' -> 'let'.
rdar://problem/23172698
Swift SVN r32855
<slight revision of yesterday's reverted commit>
The debugAsserts were nicely self-documenting, but generate an obscene
amount of useless SIL code that is inlined everywhere and sticks around
when we compile the stdlib. The old asserts would need to be fixed to
support Optionals but that makes the situation much worse.
Why is it ok to remove the asserts?
_unsafeReferenceCast remains an internal API.
If the src/dest types are not loadable reference types, the cast will
not be promoted to a value bitcast.
The remanining cases will be dynamically checked by swift_dynamicCast.
Swift SVN r32828
Revert "For unsafeReferenceCast rely on static verifier checks."
This reverts commit r32796.
This reverts commit r32795.
They very likely broke a buildbot.
Swift SVN r32813
unsafeBitCast should only be used when we actually need to lie to the type system (as opposed to just having an unchecked downcast).
Theses are the places where unsafeReferenceCast makes sense:
(In general it makes sense whenever the source & dest are class or class existential types)
- ArrayBuffer.getElement.
The deferred downcast case cannot be benchmarked. It is never on the critical path.
The ObjC array case cannot conceivably matter either, however, it is touched by
DollarChain, JSONHelperDeserialize, and StrSplitter.
These benchmarks do not regress at -O.
- arrayForceCast
No regressions at -O based on microbenchmarks.
None of these remaining cases affect PerfTestSuite at -O:
- General ObjC bridging
- Set/Dictionary bridging
- String bridging
- AutoreleasingUnsafeMutablePointer
These are confirmed speedups but I did not investigate the cause:
|.Chars...................|.32.1%.|
|.Sim2DArray..............|.15.4%.|
|.Calculator..............|.13.0%.|
|.RecursiveOwnedParameter.|..7.9%.|
Swift SVN r32796
The debugAsserts were nicely self-documenting, but generate an obscene
amount of useless SIL code that is inlined everywhere and sticks around
when we compile the stdlib. The old asserts would need to be fixed to
support Optionals but that makes the situation much worse.
Why is it ok to remove the asserts?
_unsafeReferenceCast remains an internal API. The invariants are checked
statically whenever the routine is specialized, and dynamically checked
by the runtime cast.
Swift SVN r32795
Generally avoid casting to a raw pointer unless a raw pointer is needed.
Builtin.castReference is now the canonical way to cast reference types.
Canonical generally = better optimizer. In practice this will reduce to
the same SIL since the stdlib code will be optimized.
There are enough unit tests for unsafeDowncast and Builtin.castReference.
I measured no performance regressions.
Swift SVN r32646
_unsafeCastReference allows casting of any references types, regardless
of whether they are references to objects or class existentials. The
implementation is responsible for converting between representations.
_unsafeCastReference provides a dynamic check to ensure that the source
and dest are both actually references. If not, the implementation will
trap at runtime. Generally, the optimizer can prove that the source
and dest are references, and promote this cast to an
unchecked_ref_cast bitcast. There is no dynamic check that the
references types are compatible.
This differs from unsafeDownCast in two ways:
(1) The source and dest types are not statically typed
AnyObjects. Therefore, unsafeCastReference can be used when the
surrounding code dynamically handles both reference and nonreference
types.
(2) The source and dest also need not dynamically conform to AnyObject.
Either side of the cast may be a class existential. The primary
requirement is that the source and dest refer to the same reference
counted object.
Swift SVN r32588
This avoids unnecessary address-taking. Instead use the builtin that directly
supports unsafe casts. The optimizer now follows clear rules for
Builtin.reinterpretCast (so it's safe to use) and knows how to optimize it.
Swift SVN r32268
Instead of Optional entries use a third bitmap array to mark whether an entry is
valid. This representation saves space (because individual entries don't have a
alignment padding slack) and simplifies ARC's job leading to better performance.
Speedup measured (before/after) at -O:
DictionaryHashableClass`````````3.1
DollarFilter````````````````````1.3
DollarMap```````````````````````1.3
DollarReduce````````````````````1.4
JSONHelperDeserialize```````````1.4
NSDictionaryImplicitConversion``1.4
NSXMLParser`````````````````````1.3
Speedup measured (before/after) at -Onone:
DictOfArraysToArrayOfDicts``````1.3
Dictionary``````````````````````3.5
Dictionary2`````````````````````3.2
Dictionary3`````````````````````3.2
DictionaryHashableClass`````````1.9
DictionaryHashableStruct````````2.4
DictionaryRemove````````````````3.3
DictionarySwap``````````````````2.5
DollarFilter````````````````````1.2
DollarMap```````````````````````1.2
DollarReduce````````````````````1.3
Forest``````````````````````````1.8
Histogram```````````````````````1.6
JSONHelperDeserialize```````````1.6
NSDictionaryImplicitConversion``1.3
Prims```````````````````````````2.9
RGBHistogram````````````````````1.4
rdar://22173734
Swift SVN r32244
