Will serve as an IndexType for CollectionOfOne<T>
Open Question: should this become a full-fledged Int1 type, generated by
FixedPoint.gyb?
Swift SVN r13974
Sometimes you just need to normalize to the widest integer
type (especially in generic code), and who knows; someday we may get
Int128 back.
Swift SVN r13950
Force @objc_blocks to use the @cc(cdecl) calling convention, so that calling them undergoes bridging conversions in SILGen, and give them the correct ownership conventions so that the callee, arguments, and result are passed +0. This unfortunately ruins our ability to verify bridge_to_block instructions at all, but bridge_to_block is a hack anyway, and this is a necessary prerequisite to actually being able to call blocks in IRGen.
Swift SVN r13923
Mock up a naive Printable protocol, and do some dirty tricks in the runtime to implement a 'printAny' function that uses swift_conformsToProtocol to look up a conformance to Printable if the type has one, or falls back to a dumb opaque printing if it doesn't. Use this to make Array<T> Printable in some way or another for all T.
Swift SVN r13902
Given our constraints for 1.0, we can actually sort-of look up protocol conformances just by dlsym'ing the symbol for their protocol witness table, since we won't be implementing runtime witness table instantiation or private conformances anytime soon. To make this work for generic types, distastefully regress our mangling for protocol conformances by assuming all generic conformances are completely general to the unbound generic type and leave the generic parameters out of the mangling.
Swift SVN r13901
As part of this, have the standard library target be responsible for
symlinking Clang's headers into the resource directory, instead of the
compiler target. This makes sure the headers show up in all copies of
the build directory.
This brings our iOS testing closer to what Xcode will do, which will
hopefully avoid issues like <rdar://problem/16052579>.
Swift SVN r13890
This was supposed to be done a long time ago after DI landed, but a
weird bug in our getopt wrapper blocked this. That code is gone now, so
let's make the switch.
Swift SVN r13786
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
