Currently this only handles top-level nominal types. We're just trying to
emulate what the debugger does when it needs to go from a mangled name to
an AST node, so it's okay that the cases handled here are very restricted.
We just want to make sure that the debugger is /able/ to do what it needs
to do.
This does not yet handle nested (non-top-level) values; that will require
changes to DeclContext::lookupQualified.
Part of rdar://problem/17632175
Swift SVN r21690
In this mode, use nullability information on the result type of the
initializer or factory method to determine failability of the
initializer. This is behind the flag
-enable-objc-failable-initializers until we have the SILGen support in
place.
Swift SVN r21341
This is very basic: it just sees whether, given a set of driver arguments, the
swift::driver::createCompilerInvocation API returns a non-null
CompilerInvocation.
Unlike other modes of swift-ide-test, this mode requires that
"-test-createCompilerInvocation" be the first argument passed to swift-ide-test.
This is because it is handled separately from llvm::cl::ParseCommandLineOptions
so the remaining arguments can be passed through directly to
swift::driver::createCompilerInvocation without any interference from that
parser.
Additionally, added a test which uses this tool to try to create a
CompilerInvocation for a handful of basic driver commands.
Swift SVN r20973
Previously we only printed submodules that were imported by the
top-level module, which worked in the common case of inferred submodules
of frameworks (e.g. Foundation.NSArray), but fell over when the
submodules were explicit (e.g. OpenGL.GL), or just not imported by the
top-level module.
Swift SVN r20855
We require some level of consistency between the way the overlays were
built and what we work with in our mock SDK. The IDE/sdk_sugar.swift
test failure was because the overlay referenced "init(coder:)" while
the test was looking for "init(withCoder:)". Hilarity ensued
<rdar://problem/17791048>.
This only impacts testing.
Swift SVN r20564
We don't need module names for properties and methods, since they're
effectively unique within a class. Moreover, use all of the
distinguishing characteristics as the key for the stored
representation in the side car writer. No visible functionality
change; this is staging.
Swift SVN r20008
Extend swift-ide-test with a mode that generates a side car file from
the built-in KnownObjCMethods.def, which gives us an easy way to
source the information we want in the side car. This is a temporary
measure until we have a textual format for side car data and the
ability to translate that into the binary format.
Swift SVN r19994
Add the ability to store optionality of the ObjC method parameters and return
type in a sidecar. This hardcoded info is then used to import Objective C
object pointer types as either optional or none, instead of implicitly
unwrapped optionals.
The feature is enabled with -import-with-tighter-objc-types=true.
Swift SVN r19048
...in preparation for non-source locations, i.e. locations that don't come
frome source buffers.
No functionality change, but a fair bit of SourceManager API and idioms have
changed.
Swift SVN r18942
-Hide vars that have a private type.
-Hide functions that have a parameter with private type or a parameter name with leading underscore.
-Minor change in StringUTF16.swift to avoid printing "func generate() -> IndexingGenerator<_StringCore>".
rdar://17027294
Swift SVN r18623
