This is a better solution to <rdar://problem/16899681> because the
runtime magic is limited to implementing the witnesses of this
conformance.
The type checker fixes are because we can end up using unchecked
optionals in more places, via bridging, than we could before.
Swift SVN r18120
No functionality change.
Change signature of handleSILGenericParams to get ready for patches on parsing
specialized protocol conformance in sil_witness_table.
rdar://15722175
Swift SVN r18117
Use TypeInfo::indexArray to get the bounds of the array instead of duplicating its logic incorrectly. Fixes <rdar://problem/16916422>.
Swift SVN r18115
Empty NSArrays are usually represented by emptyNSSwiftArray, whose
element type is irrelevant. So when doing a getObjects:range: on that,
presumably the range's length is zero and we shouldn't do any sanity
checking w.r.t. the element type.
Fixes <rdar://problem/16914909> Assertion failed attempting to append
arrays when subclassing Cocoa class
Swift SVN r18110
This allows us to, for example, convert an array of unchecked
optionals of some bridged type T to NSArray. It's a runtime failure if
the unchecked optional contains nil.
This is most of <rdar://problem/16899681>, but I want to improve the
testing and look into the various FIXMEs.
Swift SVN r18106
String interpolation invokes convertFromStringInterpolationSegment() function
now. There is no need to add extensions to String to allow custom types to
participate in string interpolation. Just implementing Printable will do the
right thing.
Swift SVN r18104
I didn't want to rip this logic out wholesale. There is a possibility
the character lexing can be reborn/revisited later, and
disabling it in the parser was easy.
Swift SVN r18102
have been type checked. This allows us to reliably determine the type of the variable
and to know whether it actually needs default initialization or not.
This fixes:
<rdar://problem/16620121> Initializing constructor tries to initialize computed property overridden with willSet/didSet
which was because we were doing default initialization before computing override sets.
This does regress on one case, where our fiddly default init code isn't realizing that
a default initializer will be generated. I fixme'd the case and filed:
<rdar://problem/16921173> implicit constructor synthesization runs too early
to track this.
Swift SVN r18094
Drop a note in the source file containing the top-level code to make it easier to navigate to (and avoid hardcoding the magic "main.swift" name).
Swift SVN r18093
The reason that this is important is that we *ARE* allowing the stdlib
to perform certain types of type punning for efficiency implying we need
to have a type oracle instruction to have safety.
A type oracle instruction is an instruction which implies undefined behavior
unless its operand/result is of a certain type (allowing us to ignore that
possibility).
In a following commit I am going to go over and fix any problems in the
actual TBAA implementation and give all the various checks tests.
rdar://16651852
Swift SVN r18090
If a source file contains the main class for its module, then implicitly emit a top_level_code that invokes UIApplicationMain with the name of the marked class.
Swift SVN r18088
Importing a header with -import-objc-header causes the Clang importer to
provide an extra module to represent the header's content, and this was
showing up as "@import __ObjC;" in the /generated/ header for the target.
We should just not print anything there and let users import what's
necessary.
<rdar://problem/16917113>
Swift SVN r18081
This is conditionally compiled out without asserts on.
I am going to use this functionality to test basic-aa and tbaa
separately in different test files.
<rdar://problem/16651852>
Swift SVN r18075
