The driver option -i now requires an input file as argument, and any
options after the input file will be treated as arguments to the
interpretted file.
This also renames the frontend option to -interpret, since it is parsed
as a flag, unlike -i. We could support -interpret in the driver if we
wanted, which would allow us to use --, but wouldn't work with shebang
scripts. For now, it's frontend-only.
Swift SVN r19718
Previously, bridged value types and their corresponding Objective-C
classes allow inter-conversion via a number of user-defined conversion
functions in the Foundation module. Instead, make this a general
feature of the type checker so we can reason about it more
directly. Fixes <rdar://problem/16956098> and
<rdar://problem/17134986>, and eliminates 11 (half) of the
__conversion functions from the standard library and overlays.
A few notes:
- The XCTest changes are because a String can no longer directly
conform to CVarArg: this is a Good Thing (TM), because it should be
ambiguous: did you mean to pass it as an NSString or a C string?
- The Objective-C representations for the bridged collections are
hard-coded in the type checker. This is unfortunate and can be
remedied by adding another associated type to the
_BridgedToObjectiveC protocol.
Swift SVN r19618
Foundation, and have them forward to Foundation.
This is slower than it could be, but at least this way we produce correct
results.
Another part of rdar://17550187
Swift SVN r19560
This commit removes Mirrors for RangeGenerators, since Dave and I discussed that these won't be necessary in practice
Also, it removes the Mirrors for Range types from Range.swift.gyb, and instead adds a new RangeMirrors.swift.gyb used to generate range types Mirrors
Swift SVN r19543
When a user violates the inout rules by "re-entering" an array that is
currently undergoing mutation, it must not admit a memory-safety
violation. To ensure that it doesn't, temporarily make the buffer being
operated on inaccessible through the original array.
Swift SVN r19532
combinations of types and operations
This uncovered a bug in LLVM:
<rdar://problem/17549300> [FastISel?] LLVM miscompiles @llvm.smul.with.overflow.i8 on x86-64
I was adding this test in response to rdar://16359498
Swift SVN r19510
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
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
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
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
