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
resulting token goes back through the lexer to get the appropriate
token kind. Thanks to Chris for spotting this.
Also, document the '<' and '>' splitting behavior in LangRef.
Swift SVN r2192
and use this information as cues in the language. Right now,
we do not accept things like "-- *i" because the prefix
operator is not correctly right-bound; instead you have to
write "--(*i)". I'm okay with that; I did add a specialized
diagnostic recognizing operator-binary in a place where we're
expecting a potential operator-prefix.
Swift SVN r2161
protocol conformance types, e.g., 'protocol<P, Q>'. A few things
people *might* want to scream about, or at least scrutinize:
- The parsing of the '<' and '>' is odd, because '<' and '>' aren't
tokens, but are part of the operator grammar. Neither are '>>',
'>>>', '<>', etc., which also come up and need to be parsed
here. Rather than turning anything starting with '<' or '>' into a
different kind of token, I instead parse the initial '<' or '>'
from an operator token and leave the rest of the token as the
remaining operator.
- The canonical form of a protocol-composition type is minimized by
removing any protocols in the list that were inherited by other
protocols in the list, then sorting it. If a singleton list is
left, then the canonical type is simply that protocol type.
- It's a little unfortunate that we now have two existential types
in the system (ProtocolType and ProtocolCompositionType), because
many places will have to check both. Once ProtocolCompositionTypes
are working, we should consider whether it makes sense to remove
ProtocolType.
Still to come: name lookup, coercions.
Swift SVN r2066
I haven't really carefully considered whether existing type-checking etc. is correct for the main module (I think the name-binding rules need to be a bit different?), but it seems to work well enough for the obvious cases.
This is enough to get the one-liner "println(10)" to print "10" in "swift -i" mode, although the path to swift.swift still needs to be explicitly provided with -I.
Swift SVN r1325
The later could represent semantic errors, but we'd rather represent those with an
ExprError node instead. This simplifies the code and allows the parser to build a more
fully-formed AST that IDE clients will like.
Swift SVN r1141
but not operators. Audit calls to make sure that we use the right one
in the right places. This allows us to reject structs named * for example.
Swift SVN r1127
it doesn't appear in places it shouldn't. The only limits on
this checking right now is the inadequacy of location information
for types, which is something we ought to fix.
Fix type-checking of byref applications. Fix IR generation
of byref variables. Whole lotta fixin' goin' on.
But hey, byref calls work.
Swift SVN r1111
aren't needed for the lexer proper (which just needs a buffer to dig
through). Also, make it possible to suppress lexer diagnostics merely
by not giving it a diagnostic engine to work with.
Swift SVN r852
Also use the new getAdvancedLoc() method instead of hacking
on SMLoc directly.
Also fix the warning/note/error methods to forward through ASTContext
instead of being replicated everywhere.
Swift SVN r750
diagnostics over to it.
There are a few differences between this diagnostic engine and Clang's
engine:
- Diagnostics are specified by a .def file (Diagnostics.def), rather
than via tblgen, which drastically simplifies the build and makes
code completion work when you add a new diagnostic.
- Calls to the "diagnose()" method are safely typed based on the
argument types specified in the .def file, so it's harder to write a
diagnostic whose expected arguments (in the string) and whose actual
arguments (in the code) don't match.
- It uses variadic templates, so it hangs with the cool kids.
Swift SVN r734
