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
As the initial step, we remove any synthesized extensions requiring a tuple's conforming to nominals, which
never happens. This will remove multiple useless synthesized extensions for Dictionary.
We can have multiple printDeclPre callbacks pending (e.g top-level-code
decls), so use a vector to ensure we don't lose the earlier callbacks.
We also may end up calling printDeclPost without forcing the
corresponding printDeclPre first if the decl doesn't actually print
anything (e.g. an if-config statement when skipping those). So add a
wrapper callPrintDeclPost that can check for this and skip both
callbacks. In theory, we could handle this case by instead making all
ast nodes go through something like shouldPrint() and making an
invariant that something will be printed if and only if shouldPrint
returns true. However, that is not an obvious win, because it forces us
to walk all the first-level statements and decls inside a top-level-code
decl to determine if anything will be printed, and it also means we can
never make local decisions about whether something will be printed. For
now, I've chosen to maintain flexibility by recovering from unprinted
decls.
Finally, add a bunch of assertions to try to keep callbacks sane.
... 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
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
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.
Clang and Swift decls likely have many-to-one mappings; for instance,
a RecordDecl and a TypedefDecl in Clang are both imported as the same Swift
NominalTypeDecl. This commit reduces duplication when we print Clang decls in
Swift. rdar://23275959
Instead of importing everything and filtering later (so all of clang modules get deserialized and associated Swift decls get created),
lazily import as Swift decls only the Clang decls that we need from a particular header.
This also fixes printing ObjC categories in the header as Swift extensions.
Swift SVN r28358
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
This translates clang arguments to swift ones, uses the bridging header
functionality to parse the provided file, and re-uses part of the module interface
printing implementation to print an interface for the header.
Part of rdar://19939192
Swift SVN r28062
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
Also print the extensions for nested types (either nested within a
nominal type decl, or within another extension). This fixes printing
the String.UTF*View.Index types in the generated module interface for
the stdlib
Swift SVN r25352
We don't do this very efficiently, but it does work. And now that it's working,
drop some special cases in module interface printing -- just always print
Clang decls in Clang source order.
Swift SVN r21901
The former is for debugging, the latter is for detailed presentation to users.
swift -print-ast will continue using printEverything, as will swift-ide-test,
but all other features should use printVerbose.
Swift SVN r20432
