At the time this code was written, the logic to find a Decl from a
demangled name still lived in LLDB. Now that it's been sunk into
libIDE, we can test the actual behavior, though I've changed it to
find declarations rather than types.
...by mangling them the same as any other value decl. This is important for debug info to
preserve and recover a private typealias.
rdar://problem/24921067
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
This works using the nominal's normal lookupDirect to gather decls from the
original declaration and all its extensions, then filters them by module and
private-discriminator. This does not yet do the right thing for extensions
because we don't include the extension's module in a member's mangling except
in very specific circumstances. In order to make this work in general we'll
have to start doing this more generally.
Part of rdar://problem/17632175
Swift SVN r21785
...unless you've provided a discriminator. "No discriminator" does not mean
"show me everything"; that's what normal, non-discriminated lookup does when
you've turned off access control.
Swift SVN r21783
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
