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.
Although omit-needless-words is almost entirely a Clang importer task,
there are a handful of other places in the compiler that will need to
query this flag as well. NFC for now; those changes will come soon.
This utility helps us reconstruct type from a mangled name. SourceKit needs this functionality to deliver
richer doc-info/cursor-info.
Thanks for Sean's help!
This commit changes the Swift mangler from a utility that writes tokens into a
stream into a name-builder that has two phases: "building a name", and "ready".
This clear separation is needed for the implementation of the compression layer.
Users of the mangler can continue to build the name using the mangleXXX methods,
but to access the results the users of the mangler need to call the finalize()
method. This method can write the result into a stream, like before, or return
an std::string.
to make sure we are not accessing the buffer before the output is ready. The Mangler is going to be buffered (for compression), and accessing the underlying buffer is a bug.
We decided not to support "implicit" properties, where we import
getter/setter pairs as properties. Rather, we only import a property
when there is an explicit "@property" in Objective-C. Remove the flag
and supporting code for implicit properties.
This places enumerators that will become either cases of a Swift enum
or options in a Swift option into the context of the C enum type for
the name lookup table.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
