initialization in-place on demand. Initialize parent metadata
references correctly on struct and enum metadata.
Also includes several minor improvements related to relative
pointers that I was using before deciding to simply switch the
parent reference to an absolute reference to get better access
patterns.
It is a common problem that people use a call to a function with a
trailing closure in a if condition, foreach loop, etc. These don't allow
trailing closures, because they are ambiguous with the brace-enclosed body
of the conditional statement.
In an effort to improve QoI on this, perform lookahead to disambiguate the most common
form of this, in a very narrow situation. This allows us to produce a nice error
with fixit hints like:
t.swift:26:25: error: trailing closure requires parentheses for disambiguation in this context
for _ in numbers.filter {$0 > 4} {
^
instead of spewing out this garbage:
t.swift:26:26: error: anonymous closure argument not contained in a closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:33: error: consecutive statements on a line must be separated by ';'
for _ in numbers.filter {$0 > 4} {
^
;
t.swift:26:34: error: statement cannot begin with a closure expression
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: note: explicitly discard the result of the closure by assigning to '_'
for _ in numbers.filter {$0 > 4} {
^
_ =
t.swift:26:34: error: braced block of statements is an unused closure
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:18: error: type '(@noescape (Int) throws -> Bool) throws -> [Int]' does not conform to protocol 'Sequence'
for _ in numbers.filter {$0 > 4} {
^
t.swift:26:34: error: expression resolves to an unused function
for _ in numbers.filter {$0 > 4} {
^
If this option is enabled, when generating potential bindings for a type
variable, don't propagate IUO type. Instead try the optional type and
the underlying type. This way, untyped bindings will not be given IUO
type when they are initialized with exprs of IUO type.
When the selector named by Selector("foo") does not map to a known
Objective-C method, allow one to suppress the warning by wrapping the
string literal in an extra set of parentheses, e.g.,
Selector(("foo"))
Suggest this via a Fix-It on a note so it's discoverable. Addresses
rdar://problem/24791200.
This was mistakenly reverted in an attempt to fix buildbots.
Unfortunately it's now smashed into one commit.
---
Introduce @_specialize(<type list>) internal attribute.
This attribute can be attached to generic functions. The attribute's
arguments must be a list of concrete types to be substituted in the
function's generic signature. Any number of specializations may be
associated with a generic function.
This attribute provides a hint to the compiler. At -O, the compiler
will generate the specified specializations and emit calls to the
specialized code in the original generic function guarded by type
checks.
The current attribute is designed to be an internal tool for
performance experimentation. It does not affect the language or
API. This work may be extended in the future to add user-visible
attributes that do provide API guarantees and/or direct dispatch to
specialized code.
This attribute works on any generic function: a freestanding function
with generic type parameters, a nongeneric method declared in a
generic class, a generic method in a nongeneric class or a generic
method in a generic class. A function's generic signature is a
concatenation of the generic context and the function's own generic
type parameters.
e.g.
struct S<T> {
var x: T
@_specialize(Int, Float)
mutating func exchangeSecond<U>(u: U, _ t: T) -> (U, T) {
x = t
return (u, x)
}
}
// Substitutes: <T, U> with <Int, Float> producing:
// S<Int>::exchangeSecond<Float>(u: Float, t: Int) -> (Float, Int)
---
[SILOptimizer] Introduce an eager-specializer pass.
This pass finds generic functions with @_specialized attributes and
generates specialized code for the attribute's concrete types. It
inserts type checks and guarded dispatch at the beginning of the
generic function for each specialization. Since we don't currently
expose this attribute as API and don't specialize vtables and witness
tables yet, the only way to reach the specialized code is by calling
the generic function which performs the guarded dispatch.
In the future, we can build on this work in several ways:
- cross module dispatch directly to specialized code
- dynamic dispatch directly to specialized code
- automated specialization based on less specific hints
- partial specialization
- and so on...
I reorganized and refactored the optimizer's generic utilities to
support direct function specialization as opposed to apply
specialization.
This split the function signature module pass into 2 functin passes.
By doing so, this allows us to rewrite to using the FSO-optimized
function prior to attempting inlining, but allow us to do a substantial
amount of optimization on the current function before attempting to do
FSO on that function.
And also helps us to move to a model which module pass is NOT used unless
necesary.
I do not see regression nor improvement for on the performance test suite.
functionsignopts.sil and functionsignopt_sroa.sil are modified because the
mangler now takes into account of information in the projection tree.
This is crashing while emitting metadata for Foundation:
temporarily turning this off while I investigate locally.
https://bugs.swift.org/browse/SR-994
John McCall
danra
Xi Ge
Chris Lattner
Doug Gregor
Michael Gottesman
Chris Lattner
Dan Raviv
practicalswift
Dmitri Gribenko
Chris Willmore
Andrew Trick
Ben Langmuir
Joe Groff
Ben Langmuir
Xin Tong
David Farler