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.
Move the ObjC internal declarations to a public runtime header so they can be shared, and rename _swift_deallocClassInstance to the more descriptive name swift_rootObjCDealloc (and make it only available with ObjC interop).
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
libSystem on OS X (and therefore the Darwin module) includes all the functions
that are present in libpthread/libld on Linux. So go ahead and pull those in for
parity.
<rdar://problem/23207607>
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.
This is an optional feature that is off by default, and is enabled by
passing -- -build-swift-dispatch-overlay=1 to utils/build-script.
The libdispatch build I was testing with was old and is missing some
symbols, so perhaps some of the stuff can move out of #if protection
later.
There isn't much here yet, and no tests either.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
The swift_unknown* entry points are not available on the Linux port.
Previously we would still attempt to use them in a couple of cases:
1) Foreign classes
2) Existentials and archetypes
3) Optionals of boxed existentials
Note that this patch changes IRGen to never emit the
swift_errorRelease/Retain entry points on Linux. We would like to
use them in the future if we ever adopt a tagged-pointer representation
for small errors. In this case, they can be brought back, and the
TypeInfo for optionals will need to be generalized to propagate the
reference counting of the payload type, instead of defaulting to
unknown if the payload type is not natively reference counted.
A similar change will need to be made to support blocks, if we ever
want to use the blocks runtime on Linux.
Fixes <rdar://problem/23335318>, <rdar://problem/23335537>,
<rdar://problem/23335453>.
This will let us eventually do tagged pointer optimization for small error values. We don't take advantage of this in IRGen yet, but we can take advantage of it in the dynamic cast code in a few places, so it gets exercised, and doing this now will let us backward-deploy the optimization when we do implement it in the future.
Make the following illegal:
switch thing {
case .A(var x):
modify(x0
}
And provide a replacement 'var' -> 'let' fix-it.
rdar://problem/23172698
Swift SVN r32883
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
In cases where our major version of clang is different than the
installed clang this allows us to install the builtin headers ourselves.
This should be used judiciously, since it installs to a path 'owned' by
clang.
Swift SVN r32696
