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 reverts commit r28387. It causes SIL linkage issues on the bots, and several people have noted that -sil-serialize-all is a better approach.
Swift SVN r28391
Expose constructors, ==, and other operators so they can be inlined down to their underlying C struct operations. Add overlays for CG{Point,Rect,Size}Zero and CGAffineTransformIdentity as well so we avoid having to load from the opaque extern storage of the C constants. rdar://problem/20888179
Swift SVN r28387
With bitcode enabled, the XCTest overlay fails to link because
XCTest.framework itself was not built with bitcode. For now, we should
not build this overlay with bitcode. It isn't embedded in apps.
rdar://problem/20884313
Swift SVN r28355
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
The non-Darwin build uses std::once_flag, which has a nontrivial constexpr ctor, so it still meets the requirement we care about that it doesn't cost a global constructor.
Swift SVN r28275
