* Added a mode in swift-ide-test to test code completion. Unlike c-index-test,
the code completion token in tests is a real token -- we don't need to
count lines and columns anymore.
* Added support in lexer to produce a code completion token.
* Added a parser interface to code completion. It is passed down from the
libFrontend to the parser, but its functions are not called yet.
* Added a sketch of the interface of code completion consumer and code
completion results.
Note: all this is not doing anything useful yet.
Swift SVN r6128
If -nsstring-is-string is enabled, lower Strings in cc(c) and cc(objc) function types to NSString, and when calling them, insert calls to StringToNSString/NSStringToString to perform the bridging conversion.
This isn't quite ready for prime-time yet, because we still need to emit the inverse bridging for ObjC method thunks, and I haven't tested the IRGen end of things yet.
Swift SVN r5355
by the SIL parser. Add a test that covers both local types, and types
that require looking through an import decl (Int, from the stdlib).
Swift SVN r5249
We can bikeshed on this later, but for now we can use a very explicit
extension that has no chance of stepping on any existing extension.
Swift SVN r5239
Eventually this will include both modules and source files that the
emitted module depends on, but for now it's just going to be used for
testing purposes to forward to normal source loaders.
Swift SVN r5108
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
