Every Swift module starts with an implicit "import swift", so why not use
that to hold all of the runtime info we need?
This only gets us copying the header (and its module map) into include/swift/.
It doesn't actually use it yet.
Swift SVN r13617
This re-applies r13380, reverted in r13406. I don't think this actually
caused any harm (r13400 was the primary culprit), but if it did I'd
like to actually see the buildbots or someone else's machine fail on it.
Swift SVN r13456
This substitutes swift_driver in as the new "swift". Tests that currently
test "%swift" will invoke "swift -frontend", much like "clang -cc1".
Most command-line interaction will look the same, except that Swift can
now emit linked libraries (using -emit-library) and executables (using
-emit-executable, or by not passing a mode option at all).
If you are working with @transparent functions, note that they will not be
properly inlined across file boundaries unless you use
-force-single-frontend-invocation, which emulates the old swift binary.
There are Radars for this already: <rdar://problem/15366167&15693042>
The name 'swift_driver' is now a symlink for 'swift'. This will be removed
next week.
The old 'swift' is still available as 'swift_old', though it is not being
tested at all. This will be removed in two weeks.
Clean CMake builds will get this immediately.
Incremental CMake builds will not get the new driver unless you explicitly
enable the SWIFT_NEW_DRIVER option (-DSWIFT_NEW_DRIVER=ON on the command line).
This option will go away in a week.
Makefile builds will get this immediately because I didn't want to work out
how to maintain both modes.
Much credit to Connor for bringing up the entire driver and for doing much
of the work in ensuring that all the tests continue to pass.
Swift SVN r13380
This is easier for out-of-process clients like LLDB or DTrace to understand, and will let us mess with the runtime metadata cache data structure without forcing churn on the debugger team.
Swift SVN r13221
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
The previous attempt at this failed because tuple type metadata was laid out in a way that smashed the metadata cache key. Cache keys used to be laid out like this:
CacheEntry struct
-----------------
cache key
-----------------
variable-sized payload
And TupleTypeMetadata tried to tail-emplace its element array immediately after the main CacheEntry, forgetting the cache key was there. When we actually try to use that cache key to implement a hash table, bad things happen. Rearrange cache entries into the less error-prone layout:
cache key
-----------------
CacheEntry struct
-----------------
variable-sized payload
This also nicely avoids the need for a dynamic offset from the CacheEntry struct to its payload. A tail-allocated payload is likely to be more hot than the cache key, which is only needed at instantiation and lookup time.
Swift SVN r13205
- Int and UInt are now struct types backed by Builtin.Word. Previously they
were typealiases for Int64; Int and Int64 are now distinct types.
- Mangled names 'i' and 'u' are now Int and UInt. Int64 is mangled longhand.
- Word is a typealias for Int. It is expected to go away in the future.
- Builtin.Word is unchanged.
- CLong and CUnsignedLong are typealiases for Int and UInt.
- FixedPoint.swift is now FixedPoint32.swift and FixedPoint64.swift.
Reunifying these requires better builtins, especially for checked
conversions (rdar://15472770).
- Updated many tests, mostly because Int is no longer spelled Int64 in sil.
- One check was removed from test decl/operator/operators.swift
because it changed behavior when Int became a non-typealias
type (rdar://15934688).
Swift SVN r13109
When SWIFT_OPTIMIZED is not set, add a little extra memory debugging,
which doesn't seem to slow anything down noticeably and can be disabled
as needed.
This change only affects the CMake build because that's the only place
where SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS is supported already. We may
want to extend this to the Makefile build.
Swift SVN r13008
Using a linked list for metadata caches is pretty lame. Pull in llvm::DenseMap and hash_combine_range and use them to index instantiated metadata.
Swift SVN r12998
The facility we had before was not very usable in core elements of the
standard library because it relied too much on those elements itself.
The result could be some spectacular infinite recursions and general
erosion of certainty, and was making development of Swift's String very
difficult.
In this commit we use extremely low-level primitives to avoid the recursion
problem. Also, because the purpose of all the older assertion functions
was unclear and there was a great deal of overlap in terms of
functionality, we clarify naming and consolidate functions.
As much as possible, the semantics of all existing tests in the face of
Asserts-enabled/-disabled build configuration changes has been
preserved, but the new naming makes it obvious in some cases that the
semantics may not have been well-chosen, which speaks well for the new
names. (**)
The two forms of "assert()" are completely enabled or
disabled--including evaluation of the condition--based on build
configuration. This follows the usual semantics from C, with the
differences being:
* No multiple evaluation badness from preprocessor macros, of course
* When a condition is supplied, assert accepts an optional message
* When no condition is supplied, fires unconditionally and requires a
message
The other functions are always enabled and only differ between build
configurations in how much information they attempt to deliver through
non-core-dump channels. When assertions are disabled and these
functions fire, they invoke a debugger trap, and do nothing else.
(**) It also opens some questions about policy. For example, should we
consider overflow and underflow to be securityChecks, as we do now, even
though they do not directly cause a memory safety issue? We could wait
for e.g. bounds checking on arrays to catch those problems before they
become memory safety issues, and gain a little speed in the regular
arithmetic path.
Swift SVN r12854
This lets IRGen avoid emitting an alloca for common generic metadata instantiations. These entry points can also be marked "readnone", and the general getGenericMetadata entry point can be "readonly", giving LLVM's optimizer a fighting chance on unspecialized generic code.
Swift SVN r12789
The core datastructure of the revised and optimized String Design Redux,
Part Trois. Completely untested and not wired into anything, so NFC.
Swift SVN r12701
...which would of course prevent them from being used. Sadly, this includes
the one I just added, since I didn't actually test it against the original
project until now.
Add a regression test that all block shims have valid manglings without
any unmangled suffixes.
Swift SVN r12672
...which is used for the first argument to
+[NSAnimationContext runAnimationGroup:completionHandler:].
Also, use the existing shims for NSFileCoordinator's NSURL-taking blocks;
they are equivalent to the shims that take id.
We really need to figure out how to do this (a) more generically (i.e. all
id-compatible types are treated the same), and (b) on the fly for the more
esoteric block types.
<rdar://problem/15864611>
Swift SVN r12668
Going through an @objc protocol for bridging Cocoa strings to Swift
String was working, but it had several disadvantages, including the cost
of invoking objc_msgsend and the need to viciously cast away type-safety
to get past swift's ObjC bridging restrictions.
Instead, Swift's core stdlib now contains a couple of "function
pointers" (variables of Optional<some-Swift-function-type>) that are set
when Foundation is loaded. We use C++ dynamic initialization to set up
these variables, which is probably not the right long-term answer, but
works for now.
These functions, instead of invoking objc methods on NSString, go
through CFStringXXX functions, which have a fast path that avoids
objc_msgsend in Cocoa's common cases, and since they're not @objc
methods, they can use Swift's full type vocabulary.
It would still be nice to avoid any dynamic dispatch and checking
overheads for going through these optional function variables, but this
ought to be a lot better than where we were, and it keeps Foundation
decoupled from the core standard library.
Along the way, a fair amount of needless code bulk was shed. Shedding
FTW!
Swift SVN r12327
We can now run it from the repl:
Welcome to swift. Type ':help' for assistance.
(swift) benchStrings()
8808796493 nanoseconds on x86
(swift)
Swift SVN r12242
C++: ~231326 ns
ObjC: ~750604 ns
Swift: ~5827396474 ns == 25191x slower than C++!
The problems are all over the place. For example: while there are lots
of failures to inline generics, there is work in the runtime as well to
fix some cases where we call calloc() instead of use the swift cache.
Swift SVN r12225
