These APIs are from the Swift 1.2 => Swift 2.0 transition, and are not
relevant anymore.
Removing them reduces the surface area of the library that needs to be
reviewed.
This commit removes _UnsafePartiallyInitializedContiguousArrayBuffer from two
more methods. I did not measure the performance impact of this change but I am
expecting this code to run faster.
This commit simplifies map() of collections into a simple append-loop. The Swift
optimizer can do a better job optimizing code without unsafe constructs. This
change accelerates the MapReduce benchmark by 2x.
This allows removal of the DebugDescription protocol which is invalid
because no classes actually conform to it. The problem is that we need
to send a debugDescription message to an NSObject without loading
Foundation. This is exactly what shims are for. A very simple shim
solves the problem.
Adding a conformance to Foundation doesn't work because NSString can
be used without loading Foundation. debugDescription is one example of
this.
The only value we derive from the _CocoaStringType is its name, which
makes some APIs more readable. Adding a type safe wrapper around it
serves no purpose since we're almost always immediately casting back
and forth from an 'id'. This was previously done with unsafeBitCast,
which should be avoided unless we really need to reinterpret a bit
pattern.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
Getting the name of a type seems like reasonable core runtime functionality, and something the runtime can cache on its side too. Have the function return a pointer to a raw string in memory owned by the runtime, and have it be wrappen in a Swift.String on the standard library side.
We don't really need its peculiar behavior characteristics; its uses in the legacy mirror implementations can now be replaced by direct stringification of metatypes.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
Since `dropFirst` does not return an `Optional`,
`unsafeUnwrap(xs.dropFirst())` first implicitly wraps result of
`dropFirst` into an optional and then calls `unsafeUnwrap` on that.
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
