We were rounding the size up to the alignment when allocating a new object (swift_allocObject) but not when directly allocating memory for a non-object (swift_slowAlloc). The deallocation code wasn’t rounding the size up to the alignment at all. Overall, this meant that we would get the wrong index into the allocation cache when deallocating an object whose size got rounded in a way that affects the index.
Fixes <rdar://problem/17542859>, where println(5) would fail on the 32-bit iOS simulator when building the runtime without NDEBUG (so we get extra checking) and the standard library is built without optimization (which keeps a certain 33-byte allocation on the heap). The Interpreter/SDK/objc_cast.swift test triggers this when built under those conditions.
Swift SVN r19499
Using ..< and ... on RandomAccessIndex endpoints now produces a distinct
RandomAccessRange type that can have zero-based indexing, validation at
creation, efficient strides (the other Range should probably lose its
stride capability), and all kinds of other goodness. This is the first
step in solving our cluster of outstanding Range-related issues.
Swift SVN r19497
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
trie parameters and fix a few bugs
The bugs did not affect correctness of the particular instance of trie created
for grapheme cluster property, because trie parameters that were confused with
each other happened to be equal.
Also, fix a trie size bug: we were creating a trie large enough to store
information for 0x200000 code points, but there are only 0x10ffff. It saved
only 15 bytes in the grapheme cluster tree, because that extra information was
compressed with some supplementary planes that also had default values. This
also improved trie generation time by almost 2x.
Swift SVN r19457
We're temporarily using @semantics until we have mandatory inlining of branch hints.
We now have @noinline, which helps a lot, but:
- @noinline and "cold/slow" are not the same thing.
- Some functions may need to be inlined into hot paths, but that
doesn't mean we should also inline them into cold paths.
- It is easier to find cold blocks than to look for blocks that
contain calls to @noinline functions. And that doesn't necessarilly
mean the blocks are cold anyway.
Swift SVN r19455
COMPILE_FLAGS is currently used for two purposes:
- For any target library, add the appropriate Swift optimization flags. This eliminates the add_swift_optimization_flags boilerplate and makes these flags work for all library variants
- For the runtime, pass the appropriate define down when SWIFT_RUNTIME_CLOBBER_FREED_OBJECTS is set, so that all library variants get this setting.
Swift SVN r19444
This consolidates the \x, \u, and \U escape sequences into one \u{abc} escape sequence.
For now we still parse and cleanly reject the old forms with a nice error message, this
will eventually be removed in a later beta (tracked by rdar://17527814)
Swift SVN r19435
This does not yet handle variables with inferred types, since those don't
have TypePatterns.
There is some nasty propagation of @public into the stdlib because of this
one, mainly because Foundation needs access to some of the implementation
details of Array and Dictionary. We may want to try to improve this later
(or just build Foundation with -disable-access-control if it comes to that).
Swift SVN r19432
Use this for the Swift runtime’s dependency on Foundation, rather than a hack later on. This is part of getting the runtime to build for all of the variants.
Swift SVN r19406
The one design choice here was whether to expose the pointee directly through the Mirror
My choice was against that. Instead, we present UnsafePointer as UnsafePointer(0x123) and the child we expose is the 0x123 numeric pointer value
The other option, of course, would be to present it as UnsafePointer(reflect(memory)) - but that seems risky to do by default
UnsafePointers are allowed to be in, guess what, unsafe states, and the stakes of having playgrounds try and dereference at all times are quite too high.
If the user really wants to reflect the pointee reflect(pointer.memory) will do it for them - and then any crashes will be theirs to enjoy.
Of course, I am very open to arguments as to why reflect(memory) would be a better choice.
Swift SVN r19386
...unless the type has less accessibility than the protocol, in which case
they must be as accessible as the type.
This restriction applies even with access control checking disabled, but
shouldn't affect any decls not already marked with access control modifiers.
Swift SVN r19382
- Follow LLVM conventions for emacs mode specification
- Use local variables suffix to make the output read-only (at least on
Emacs)
- But drop the admonitions not to edit the generated files;
line-directive mostly takes care of that problem now.
Swift SVN r19381
