Operators in non-global scopes other than protocols don't work. Disable
them for now. We can always revisit this later.
This "fixes": 13002566 Operators not found in structs
Swift SVN r3828
We have no intention of ever supporting actual semicolon statements
(separators, statements no), nor do we ever want to because that would
mean the behavior of the program would potentially change if semicolons
were naively removed.
This patch tracks the trailing semicolon now in the decl/expr/stmt,
which will enable someone to write a good "swift indent" tool in the
future.
Swift SVN r3824
Back when we started the project, we didn't have modules, a standard
library, or even the "asmname" attribute. Not requring function bodies
provided a quick way to prototype the language. We're long past that day
now.
If you still want or need a pure declaration, the [asmname="..."]
attribute still does not require a function body.
This fixes:
13036833 Syntax ambiguity between selector function decl syntax and top-level code
Swift SVN r3821
This works now instead of giving a trail of parse errors:
var x : Int, y : Int { get { return 42 } }
This is now an explicit error rather than a trail of parse errors:
var x, y : Int { get { return 42 } }
Swift SVN r3811
By splitting out the expression used to allocate 'this' (which exists
in the AST but cannot be written in the Swift language proper), we
make it possible to emit non-allocating constructors for imported
Objective-C classes, which are the only classes that have an
allocate-this expression.
Swift SVN r3558
Currently only used for parsing. The immediate intent of these attributes is
to have them behave like [objc] for the purpose of emitting method
implementations; however, they are semantically distinct and should only be
used to expose outlets and actions to Interface Builder.
Swift SVN r3416
This implementation is very lame, because we don't currently have a
way to detect (in Sema or SIL) where 'this' gets uniquely assigned,
and turn that assignment into initialization.
Also, I'm starting to hate the name 'allocating' constructor, because
it's the opposite of the Itanium C++'s notion of the allocating
constructor. Will think up a better name.
Swift SVN r3347
Instead of writing in an awkward special case for SemiStmt in ParseStmt, apply the existing semicolon-eating syntax in ParseDecl for types to the toplevel. Suggested by Jordan re: r3336.
Swift SVN r3342
rdar://12315571
Allow a function to be defined with this syntax:
func doThing(a:Thing) withItem(b:Item) -> Result { ... }
This allows the keyword names in the function type (in this case
`(_:Thing, withItem:Item) -> Result`) to differ from the names bound in the
function body (in this case `(a:Thing, b:Item) -> Result`, which allows
for Cocoa-style `verbingNoun` keyword idioms to be used without requiring
those keywords to also be used as awkward variable names. In addition
to modifying the parser, this patch extends the FuncExpr type by replacing
the former `getParamPatterns` accessor with separate `getArgParamPatterns`
and `getBodyParamPatterns`, which retrieve the argument name patterns and
body parameter binding patterns respectively.
Swift SVN r3098
Outside of a container, semicolons after decls are just parsed as SemiStmts.
Inside a container, though, we only allow decls...but we should still allow
trailing (delimiting?) semicolons.
If you have multiple semicolons in a row, though, that's probably a typo,
so parseDecl will now also complain (error) if it sees a semicolon where
a decl is expected.
<rdar://problem/12540877>
Swift SVN r3051
static method to call it, to make it more explicit what is happening. Avoid
using TypeLoc::withoutLoc for function definitions; instead, just use an empty
TypeLoc.
Swift SVN r2606
This is much more convenient for IRGen, and gives us a reasonable representation for a static
polymorphic function on a polymorphic type.
I had to hack up irgen::emitArrayInjectionCall a bit to make the rest of this patch work; John, please
revert those bits once emitCallee is fixed.
Swift SVN r2488
have a record of how the member is being specialized for the given
context. To do this, I also had to patch up the DeclContext for
template parameters.
Swift SVN r2483
analysis for patterns.
Major changes:
1. We no longer try to compute the types of functions in the parser.
2. The type of a function always matches the type of the argument patterns.
3. Every FuncDecl now has a corresponding FuncExpr; that FuncExpr might not
have a body, though.
4. We now use a new class "ExprHandle" so that both a pattern and a type
can hold a reference to the same expression.
Hopefully this will be a more reasonable foundation for further changes to
how we compute the types of FuncDecls in generics and for the implementation
of type location information.
Swift SVN r2370
method to initialize the members. This doesn't matter so much
for structs (the generated IR is essentially equivalent except for
small structs), but on classes, we don't want to make "new X" generate
code that knows about metadata/destructors/etc for the class X.
Also, make sure classes always have a constructor. (We haven't really
discussed the rules for implicitly declared constructors, so for now,
the rule is just "generate an implicit constructor if there is no
explicit constructor". We'll want to revisit this when we actually
design object construction.)
Swift SVN r2361
the various NominalDecl subclasses into a single NominalType* member
in NominalDecl. Use it to make TypeDecl::getDeclaredType() more
efficient/simpler, and simplify the ProtocolDecl/ProtocolType
interaction along the way.
No functionality change.
Swift SVN r2298
There are currently two places where you can use a static function defined on a protocol:
on an object with the type of the protocol (discarding the base), and on an archetype in a generic function. The AST for the protocol object case is probably okay;
the AST for the generic case is almost certainly wrong, but that whole area isn't really stable at the moment anyway. The proposal in rdar://problem/11448251 will
add a third way: operators on protocols will be found by overload resolution. (Having static functions on protocols opens up the possibility of metaprotocols,
but I don't think I need to worry about that for the moment.)
Swift SVN r2211
introduce the generic type parameters (which are simply type aliases
for a to-be-determined archetype type) into scope for name
lookup. We can now parse something like
func f<T, U : Range>(x : T, y : U) { }
but there is no semantic analysis or even basic safety checking (yet).
Swift SVN r2197
