Original message:
SIL Parsing: add plumbing to know when we're parsing a .sil file
Enhance the lexer to lex "sil" as a keyword in sil mode.
Swift SVN r4988
redefinition (or linkage type) bug that causes two tests to fail. I filed
rdar://13670581 to track this and am plowing forward, since they seem minor.
Swift SVN r4761
If the completion prefix has a '.' behind it, guesstimate a context expression by lexing backward through an identifier(.identifier)* dotted path, then attempt to parse and typecheck that expression to decide on a base type in which to find completions.
Swift SVN r4063
It doesn't do anything but crash yet. Also add an entry point fo SILGen to Subsystems so that it can be invoked without dependency on SIL or SILGen.
Swift SVN r3738
generation from an expression that has not been type-checked. One can
see the constraints introduced by an expression by using
:dump_constraints <expression>
within the REPL. We're still missing several major pieces of
constraint generation:
- We don't yet "open up" references to polymorphic types
- We don't print out the child constraint systems in the dump, so
it's not at all obvious what happens within overloading (and I'm not
convinced I like my representation anyway)
- There are no tests whatsoever
- Member constraints are still very, very weird
Swift SVN r2624
This makes the two phases independently testable, but is also the
right thing to do: previously we'd form swift_retain early enough
that inlining would inline them from previously optimized callees
into callers, and this would block some mid-level optimizations
from doing nice things (because swift_retain isn't no-escape).
It's a small thing, but doing this allows us to eliminate a few
more "and x, 9223372036854775807"'s from the stdlib. We also
end up doing a lot less optimizations because we do them early
instead of only having the optimizations exposed after inlining
deeply.
Swift SVN r2114
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
