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
I chose to just delete the -lex action in swift, since it was only useful for
about 10 minutes during bringup and probably never will be again.
Swift SVN r557
