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.
Adds an associatedtype keyword to the parser tokens, and accepts either
typealias or associatedtype to create an AssociatedTypeDecl, warning
that the former is deprecated. The ASTPrinter now emits associatedtype
for AssociatedTypeDecls.
Separated AssociatedType from TypeAlias as two different kinds of
CodeCompletionDeclKinds. This part probably doesn’t turn out to be
absolutely necessary currently, but it is nice cleanup from formerly
specifically glomming the two together.
And then many, many changes to tests. The actual new tests for the fixits
is at the end of Generics/associated_types.swift.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
Instead of fail silently, issue a diagosis when a valid expression can not
be parsed for enum raw value.
This resolves [SR-510](https://bugs.swift.org/browse/SR-510).
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
This is a re-commit of ff4ea54 with an update for a SourceKit test.
This adds some heuristics so we can emit a fixit to remove extraneous
whitespace after a . and diagnose the case where a member just hasn't
been written yet better. This also improves handling of tok::unknown
throughout the parser a bit.
1. Array type parsing for postfix array types Int[]. We now handle this
in the parser, but remove the AST representation of this old form. We
also stop making vague promises about the future by saying that "fixed
size arrays aren't supported... yet". Removal of this fixes a compiler
crasher too.
2. Remove the special case support for migrating @autoclosure from types
to parameters, which was Swift 1.0/1.1 syntax. The world has moved or
we don't care anymore.
3. Remove upgrade support for # arguments (nee "backtick" arguments), which
was a Swift 1.x'ism abolished in an effort to simplify method naming
rules.
NFC on valid code.
