Example:
@available(*, unavailable, renamed: "Sequence.enumerated(self:)")
func enumerate<Seq: SequenceType>(_ sequence: Seq) ->
EnumerateSequence<Seq>
This will allow us to reuse this logic to suggest fixes for APIs
turned into members by NS_SWIFT_NAME.
It should have the same form as the argument to NS_SWIFT_NAME
in Objective-C, except that it permits operators and (currently)
disallows instance members and properties. We do get to share the
same parsing code, at least.
This actually caught an error in the Foundation overlay!
Groundwork for SR-1008.
as well as on parameter decls. Also, tighten up the type checker to look at
parameter types instead of decl attributes in some cases (exposing a type
checker bug).
Still TODO:
- Reject autoclosure/noescape on non-parameter types.
- Move stdlib and other code to use noescape and autoclosure in the right
spot.
- Warn about autoclosure/noescape on parameters decls, with a fixit to move it.
- Upgrade the warning to an error.
This fixit checks if a decl with the identical name can be found in the parent type
context; if can, we add "self." to try to resolve the issue. rdar://25389852
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.
Temporarily reverting @_specialize because stdlib unit tests are
failing on an internal branch during deserialization.
This reverts commit e2c43cfe14, reversing
changes made to 9078011f93.
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)
Mostly this was just returning the ParserStatus bits that we got from
parseExprList from parseExprStringLiteral. The rest was just cleaning up
places that didn't handle EOF very well, which is important here because
the code completion token is buried in the string literal, so the
primary lexer will walk past it.
rdar://problem/17101944
Split up parsing of typealias and associatedtype, including dropping a
now unneeded ParseDeclOptions flag.
Then made typealias in a protocol valid, and act like you would
hope for protocol conformance purposes (i.e. as an alias possibly
involved in the types of other func/var conformances, not as a hidden
generic param in itself).
Also added support for simple type aliases in generic constraints. Aliases
to simple (non-sugared) archetype types (and also - trivially - aliases to
concrete types) can now be part of same-type constraints.
The strategy here is to add type aliases to the tree of
PotentialArchetypes, and if they are an alias to an archetype, also to
immediately find the real associated type and set it as the
representative for the PA. Thus the typealias PA node becomes just a
shortcut farther down into the tree for purposes of lookup and
generating same type requirements.
Then the typealias PA nodes need to be explicitly skipped when walking
the tree for building archetype types and other types of requirements,
in order to keep from getting extra out-of-order archetypes/witness
markers of the real associated type inserted where the typealias is
defined.
Any constraint with a typealias more complex than pointing to a single
nested associated type (e.g. `typealias T = A.B.C.D`), will now get a
specialized diagnoses.
This allows us to get override completions correct when
* There are multiple decls on one line
* The preceding attributes/keywords span multiple lines
Resolving a longstanding FIXME.
There's an immediate need for this in the core libs, and we have most of the necessary pieces on hand to make it easy to implement. This is an unpolished initial implementation, with the following limitations, among others:
- It doesn't support bridging error conventions,
- It relies on ObjC interop,
- It doesn't check for symbol name collisions,
- It has an underscored name with required symbol name `@cdecl("symbol_name")`, awaiting official bikeshed painting.
in arbitrary places. This fixes a regression caught by SR-770 that
would otherwise be introduced by us removing automatic currying syntax,
it allows the use of @noescape on typealiases (resolving SR-824),
allows @noescape on nested function types (fixing rdar://19997680)
and allows @noescape to be used on local variables (fixing
rdar://19997577).
At this point, @noescape should stop being a decl attribute, but I'll bring
that up on swift-evolution.
This ireapplies commit 255c52de9f.
Original commit message:
Serialize debug scope and location info in the SIL assembler language.
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
At the moment it is only possible to test the effects that SIL
optimization passes have on debug information by observing the
effects of a full .swift -> LLVM IR compilation. This change enable us
to write targeted testcases for single SIL optimization passes.
The new syntax is as follows:
sil-scope-ref ::= 'scope' [0-9]+
sil-scope ::= 'sil_scope' [0-9]+ '{'
sil-loc
'parent' scope-parent
('inlined_at' sil-scope-ref )?
'}'
scope-parent ::= sil-function-name ':' sil-type
scope-parent ::= sil-scope-ref
sil-loc ::= 'loc' string-literal ':' [0-9]+ ':' [0-9]+
Each instruction may have a debug location and a SIL scope reference
at the end. Debug locations consist of a filename, a line number, and
a column number. If the debug location is omitted, it defaults to the
location in the SIL source file. SIL scopes describe the position
inside the lexical scope structure that the Swift expression a SIL
instruction was generated from had originally. SIL scopes also hold
inlining information.
<rdar://problem/22706994>
If behaviors are specified after the declaration, something like this:
```swift
var x: Int __behavior foo // __behavior is a stand-in keyword
```
we're thinking this encourages a simpler design for smaller, more composable behaviors. If we think of behavior application as function-like, then parameters to the behavior could be passed with function-like syntax:
```swift
__behavior lazy(@autoclosure initialValue: () -> Value) { ... }
var x: Int __behavior lazy(1738)
__behavior didSet(body: (oldValue: Value) -> Void) { ... }
var x: Int __behavior didSet {
trailingClosure()
}
```
Since behaviors are implementation details, they arguably belong to the right of the declaration as well.
There are two similar but separate code paths for conditionally
compiling declarations and statements. Previously, only statements were
properly covered with a diagnostic transaction.
rdar://problem/24844513
Since the feature is incomplete and yet to be accepted or implemented as proposed, hide it behind an -enable-experimental-property-behaviors frontend flag.
Parse 'var [behavior] x: T', and when we see it, try to instantiate the property's
implementation in terms of the given behavior. To start out, behaviors are modeled
as protocols. If the protocol follows this pattern:
```
protocol behavior {
associatedtype Value
}
extension behavior {
var value: Value { ... }
}
```
then the property is instantiated by forming a conformance to `behavior` where
`Self` is bound to the enclosing type and `Value` is bound to the property's
declared type, and invoking the accessors of the `value` implementation:
```
struct Foo {
var [behavior] foo: Int
}
/* behaves like */
extension Foo: private behavior {
@implements(behavior.Value)
private typealias `[behavior].Value` = Int
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
If the protocol requires a `storage` member, and provides an `initStorage` method
to provide an initial value to the storage:
```
protocol storageBehavior {
associatedtype Value
var storage: Something<Value> { ... }
}
extension storageBehavior {
var value: Value { ... }
static func initStorage() -> Something<Value> { ... }
}
```
then a stored property of the appropriate type is instantiated to witness the
requirement, using `initStorage` to initialize:
```
struct Foo {
var [storageBehavior] foo: Int
}
/* behaves like */
extension Foo: private storageBehavior {
@implements(storageBehavior.Value)
private typealias `[storageBehavior].Value` = Int
@implements(storageBehavior.storage)
private var `[storageBehavior].storage`: Something<Int> = initStorage()
var foo: Int {
get { return value }
set { value = newValue }
}
}
```
In either case, the `value` and `storage` properties should support any combination
of get-only/settable and mutating/nonmutating modifiers. The instantiated property
follows the settability and mutating-ness of the `value` implementation. The
protocol can also impose requirements on the `Self` and `Value` types.
Bells and whistles such as initializer expressions, accessors,
out-of-line initialization, etc. are not implemented. Additionally, behaviors
that instantiate storage are currently only supported on instance properties.
This also hasn't been tested past sema yet; SIL and IRGen will likely expose
additional issues.
As reported in SR-711, when an (unexpected) statement appears in a type
declaration, we note the beginning of the declaration in addiction to the
existing diagnostic.
class or struct conforming to a protocol. Now we produce a single error
with a fixit hint (rewriting to typealias). Before we produced:
t.swift:7:3: error: associated types can only be defined in a protocol; define a type or introduce a 'typealias' to satisfy an associated type requirement
associatedtype T = Int
^
t.swift:7:17: error: consecutive declarations on a line must be separated by ';'
associatedtype T = Int
^
;
t.swift:7:18: error: expected declaration
associatedtype T = Int
^
t.swift:6:7: error: type 'C' does not conform to protocol 'P'
class C : P {
^
t.swift:3:18: note: protocol requires nested type 'T'
associatedtype T
^
...because "build configuration" is already the name of an Xcode feature.
- '#if' et al are "conditional compilation directives".
- The condition is a "conditional compilation expression", or just
"condition" if it's obvious.
- The predicates are "platform conditions" (including 'swift(>=...)')
- The options set with -D are "custom conditional compilation flags".
(Thanks, Kevin!)
I left "IfConfigDecl" as is, as well as SourceKit's various "BuildConfig"
settings because some of them are part of the SourceKit request format.
We can change these in follow-up commits, or not.
rdar://problem/19812930
This will be used to help IRGen record protocol requirements
with resilient default implementations in protocol metadata.
To enable testing before all the Sema support is in place, this
patch adds SIL parser, printer and verifier support for default
witness tables.
For now, SILGen emits empty default witness tables for protocol
declarations in resilient modules, and IRGen ignores them when
emitting protocol metadata.
Expand the "skip" functions in the parser to be more careful about
not skipping passed a #endif or a code completion token, since they
are synchronization points for the parser.
The fix was to change Parser::delayParseFromBeginningToHere to use
a manual loop instead of skipUntil (which can stop early for non-EOF
tokens).
Swift parser splits tokens in few cases, but it swift::tokenize(...) does not know
about that. In order to reconstruct token stream as it was seen by the parser,
we need to collect the tokens it decided to split and use this information
in swift::tokenize(...).
enum raw value is parsed as a normal expression using `parseExpr()`. However,
for a closure, the parser expects a local context that doesn't exist for raw
values.
We create a temporary context to ensure the closure gets parsed as normal.
As a consequence, `parseExpr()` returns normally for closure and correct
diagnosis for raw value gets issued.
