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.
... for the fully annotated declarations. More substructure more better.
This has to go through a callback mechanism similar to printDeclLoc and
printDeclPre since it should be scheduled after both of those are
printed.
rdar://problem/24292226
For decls it can be interesting to know when a decl is a parameter vs. a
local. This will be needed for the new fully annotated decls. For refs
it's usually not interesting.
rdar://problem/24292226
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.
- Don't depend on LLVM Support and swiftBasic as this will bring in
llvmSupport and other heavy dependencies, which we don't build for
non-host architectures right now anyway.
- Add a reader template that works with the same (albeit somewhat
clunky) interface in-process with the runtime and remotely, by having
the memory tool supply a function that will copy data from the remote
process.
- Add a Buffer type to abstract indirecting pointers in a remote address
space, which is handled by the memory reader.
- Start sketching out the C remote mirrors interface.
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
This will eventually replace the existing annoteded_decl for cursor
info, and be added to doc info as well. For now put in under a
different field name to not break existing clients.
For now, just reimplement the existing annotations but put in tag names
that are specific to the kind of type/decl. The goal is to fill in a
lot more substructure/detail over time.
Incidentally flesh out some cursor info tests.
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
There's a group of methods in `DeclContext` with names that start with *is*,
such as `isClassOrClassExtensionContext()`. These names suggests a boolean
return value, while the methods actually return a type declaration. This
patch replaces the *is* prefix with *getAs* to better reflect their interface.
