Shorten the boilerplate and Put the stuff you want to match in tests at
the beginning of the lines (the resolved decl or type).
Also put the USR/mangled name into the output (at the very end), since
it is useful when trying to debug a failure.
We did not serialize them because getting USR for extensions is tricky (USRs are
usually for value decls). This commit starts to make up an USR for an extension by combining
the extended nominal's USR with the USR of the first value member of the extension. We use
this made-up USR to associate doc comments when (de)serializing them.
Pass through the original Type in addition to the TypeDecl so that we
can distinguish DynamicSelfType with underlying ClassType from just any
old ClassType.
rdar://problem/25158493
...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
For now, just tack the testing onto the existing walker that checks the
types. It doesn't seem to work at all for local declarations yet, but
at least we get some top-level stuff.
I want to start using this for other things like function types and
attributes, so rename it to reflect the new scope. I'm not really happy
with "PrintStructureKind", etc. but haven't come up with anything
better so far.
The current approach of visiting the param decl won't work when we want
to visit the parameters of function *types*, or when visiting tuple
elements (which aren't themselves decls).
rdar://problem/24292226
The Process::ResetColor() may return NULL if the LLVM library is built for Windows.
So, unguarded passing the return value to the raw_ostream may generate a crash.
The raw_ostream::resetColor() checks NULL and is used many time in the Clang.
When performing Swift API dumps, it's helpful to avoid putting
redundant APIs into the results. Therefore, filter out any APIs that
are overrides of another API or are witnesses for a protocol
requirement, since the original definition (that doesn't override any
other or is a protocol requirement) is what determines the APIs name.
The default first argument label rules are confusing reviewers looking
at API dumps. Even though it's more verbose, always put in argument
labels explicitly.
This splits the printDeclNamEndLoc callback into NameEndLoc and
NameOrSignatureEndLoc variants to differentiate whether or not
signatures are included. All existing clients move to
NameOrSignatureEndLoc to maintain the current behaviour. I'm still not
completely happy with how these are named, but I dont' have any better
ideas right now.
rdar://problem/24292226
...because "build configuration" is already the name of an Xcode feature.
- '#if' et al are "conditional compilation directives".
- The condition is a "conditional compilation expression", or just
"condition" if it's obvious.
- The predicates are "platform conditions" (including 'swift(>=...)')
- The options set with -D are "custom conditional compilation flags".
(Thanks, Kevin!)
I left "IfConfigDecl" as is, as well as SourceKit's various "BuildConfig"
settings because some of them are part of the SourceKit request format.
We can change these in follow-up commits, or not.
rdar://problem/19812930
For a concrete type, members from its conforming protocols' extensions can be hard
to manually surface. In this commit, when printing Swift modules, we start to replicate these
extensions and synthesize them as if they are the concrete type's native extensions.
Credit to Doug for suggesting this practice.
