This change attempts to introduce the functionality without being too
disruptive. After we branch, I want to consolidate some of the runtime
functions and implement this functionality for multi-payload enums
as well, which requires adding new runtime metadata.
Example:
(swift) enum Color { case Red, Green, Blue(Int) }
(swift) print(Color.Red)
REPL.Color.Red
(swift) print(Color.Blue(5))
REPL.Color.Blue(5)
Implements <rdar://problem/18334936>.
Swift SVN r28430
This change tries to recover the performance regression in map() that
was caused by moving map() to a protocol extension and degrading the
static type information (when mapping a collection, we only know that it
is a sequence). Adding map() to the witness table allows us to provide
a specialized implementation for collections, and hopefully recover the
lost performance.
Swift SVN r28416
This time with a dictionary instead of array literal, and with a test
Unless the bots break (and I will keep a more careful eye out for that this time), this will fix rdar://problem/20861708
Swift SVN r28336
Members of protocols found via unqualified name lookup are mapped to
their corresponding witnesses, as we do for qualified name
lookup. This is the bulk of the compiler changes for
rdar://problem/20509152. Performing this mapping for unqualified name
lookup of types will follow.
Swift SVN r28333
The targeted functions all take over a second to type-check with my debug
compiler (found using -debug-time-function-bodies). The top two---the two
replaceRange implementations---took about a minute each; this change
knocks them down to 30-40s.
All of this is just breaking expressions apart, and the expressions aren't
even that complicated. I'm concerned that we have a serious performance
regression around the use of lazy(), and I've filed rdar://problem/20875936
so we can look into it. The test change is particularly concerning; there's
a ridiculous difference between 'lazy(...).reverse()' and
'lazy(...).reverse().reverse()'.
No intended functionality change.
Swift SVN r28325
Rather than swizzle the superclass of these bridging classes at +load time, have the compiler set their ObjC runtime base classes, using a "@_swift_native_objc_runtime_base" attribute that tells the compiler to use a different implicit base class from SwiftObject. This lets the runtime shed its last lingering +loads, and should overall be more robust, since it doesn't rely on static initialization order or deprecated ObjC runtime calls.
Swift SVN r28219
