set by the parser. Instead of having addVarsToScope grovel through
and find them to do this, just do it directly when parsing the accessors.
Subscripts do this, so vardecls can too.
Swift SVN r13696
and add it to the release notes. Now you can elide the name on the second (or later) selector
chunk in a func declaration, and it gets implicitly named the same as the selector chunk.
This requires a speculative parse in the general case, but in the common cases
we don't need that.
Swift SVN r13691
function. Parse inout as a contextual keyword there, shoving it into the
TypedPattern (instead of introducing a new kind of Pattern). This enables
us to parse, sema, and irgen the new '@-less' syntax for inout.
Swift SVN r13559
"@mutating func f()". I'm keeping the @mutating version around
so we can determine what to do with @!mutating.
Also, improve the QoI of mutating related diagnostics.
Swift SVN r13480
with FuncDecls. This allows us to eliminate special case code for handling
self in various parts of the compiler.
This also improves loc info (debug info and AST info) because 'self' now
has a location instead of being invalid.
I also took the opportunity to factor a bunch of places creating self decls
to use similar patterns and less copy and paste code.
Swift SVN r13196
Allow IfStmts and WhileStmts to have as their condition either an expression, as usual, or a pattern binding introduced by 'var' or 'let', which will conditionally bind to the value inside an optional. Unlike normal pattern bindings, these bindings require an in-line initializer, which will be required to be Optional type. Parse variable bindings in this position, and type-check them by requiring an Optional on the right-hand side and unwrapping it to form the pattern type. Extend SILGen's lowering of if and while statements to handle conditionally binding variables.
Swift SVN r13146
mostly to get the brokenness inherent in their current representation out
of my way.
The biggest part of this is that properties in protocols are now always
represented as Computed VarDecls. If you write "var x : Int" in a protocol,
you get an getter FuncDecl. If you write "var x : Int { get}" you get the same
thing. If you write "var x : Int { get set }" then you get a getter and setter
prototype associated with the vardecl.
This then readjusts the various hacks that sort of pass through such things
in SILGen and IRGen, so that we have the same level of hacky support for properties
in protocols.
From the functionality perspective, this enables the { get set } syntax described
in rdar://15827219, and means that "var x : Int" is uniformly treated as read-only
(it was treated as mutable in some cases before). Properties in protocols are
still quite broken though.
Swift SVN r12981
1. Implement parser and sema support for our subscript syntax proposal in
protocols. Now you have to use subscript(..) { get } or {get set} to
indicate what you want. I suspect that the syntax will evolve, but at
least we can express what we need now.
2. Change the representation of SubscriptDecls in protocols to make
(empty) funcdecls for the getter and setter. This guarantees that
every subscript has at least a getter.
Swift SVN r12555
Thanks to the way we've set up our diagnostics engine, there's not actually
a reason for /everything/ to get rebuilt when /one/ diagnostic changes.
I've split them up into five categories for now: Parse, Sema, SIL, IRGen,
and Frontend, plus a set of "Common" diagnostics that are used in multiple
areas of the compiler. We can massage this later.
No functionality change, but should speed up compile times!
Swift SVN r12438
Switch some diagnostic text from 'static' over to 'type' to make
things easier, and fix up some parsing issues with selector-style
declarations found by doing this. NFC
Swift SVN r12030
This allows them to appear in argument lists of functions, enabling behavior
like this:
func test_arguments(a : Int, var b : Int, let c : Int) {
a = 1 // ok (for now).
b = 2 // ok.
c = 3 // expected-error {{cannot assign to the result of this expression}}
}
Swift SVN r11746
The parser shouldn't be diagnosing such semantic constraints. While
I'm here, allow definitions on functions in protocols (they're ignored
for now).
Swift SVN r11223
var decls. I was originally intending to use this for argument lists, but I
don't think that's a great direction to go anymore.
In any case, it seems uncontroversial to enforce immutability on foreach
enumation patterns, so I did that (see testcase)
Swift SVN r11124
This completes the FileUnit refactoring. A module consists of multiple
FileUnits, which provide decls from various file-like sources. I say
"file-like" because the Builtin module is implemented with a single
BuiltinUnit, and imported Clang modules are just a single FileUnit source
within a module.
Most modules, therefore, contain a single file unit; only the main module
will contain multiple source files (and eventually partial AST files).
The term "translation unit" has been scrubbed from the project. To refer
to the context of declarations outside of any other declarations, use
"top-level" or "module scope". To refer to a .swift file or its DeclContext,
use "source file". To refer to a single unit of compilation, use "module",
since the model is that an entire module will be compiled with a single
driver call. (It will still be possible to compile a single source file
through the direct-to-frontend interface, but only in the context of the
whole module.)
Swift SVN r10837
Build the getter and setter of a static property as static func decls, and add a verifier check that the static-ness of a var and its accessors match up.
Swift SVN r10395
The contexts for which we set the DisallowStoredVar bit, currently enums and extensions, can both (theoretically) support static variables, so change PD_DisallowStoredVar to PD_DisallowStoredInstanceVar, and allow static vars to be declared in these contexts.
Swift SVN r10350
Previously, the Parser and BranchStmt typedef-ed ExprStmtOrDecl as a pointer union. Using typedef made the objects compatible, but did not allow us to extend the type with helper methods, such as getSourceRange(), which is something you can get on all of the AST objects. This patch introduces ASTNode that subclasses from PointerUnion and is used by both parser and BranchStmt.
Swift SVN r9971
- Change type attribute printing logic (in astprinter and the demangler)
to print in the new syntax
- Change the swift parser to only accept type attributes in the new syntax.
- Update canParseTypeTupleBody to lookahead over new-syntax type attributes.
- Update the testsuite to use the new syntax.
Swift SVN r9273
Also, improve error recovery for new-syntax attributes.
This means that we now compile the testcase into:
t.swift:3:16: error: unknown attribute 'xyz'
var x : () -> @xyz Int
^
t.swift:6:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
instead of:
t.swift:4:15: error: expected type for function result
func foo() -> @xyz Int {
^
t.swift:4:14: error: consecutive statements on a line must be separated by ';'
func foo() -> @xyz Int {
^
;
t.swift:4:16: error: unknown attribute 'xyz'
func foo() -> @xyz Int {
^
t.swift:7:1: error: expected declaration
^
this is part of rdar://15183765
Swift SVN r9260
wide
Currently integer literals are 64-bit. In order to allow checking for overflow
while converting an integer literal to swift.UInt/Int* types we need at least
65 bits. But floating point numbers (Float32, Float64, Float80) are
BuiltinIntegerLiteralConvertible. In order to allow spelling large floating
point constants, we allow 136-bit literals.
Rationale: 128 bits are enough to represent the absolute value of min/max IEEE
Binary32, and we need 1 bit to represent the sign. 136 is 129 rounded to the
next 8 bits.
The plan is to have builtins that do the overflow check and convert 136-bit
numbers to the required width. We need these builtins for both integers and
floating point numbers to ensure that 136-bit numbers are folded into sane
constants in SIL and don’t escape to LLVM IR.
Swift SVN r9253
