Commit Graph

9 Commits

Author SHA1 Message Date
Andrew Trick
ff02652108 Move enums into AttrKind.h.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.

PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
2016-02-26 21:10:22 -08:00
practicalswift
a3f857ca7b [gardening] Add "-*- C++ -*-" to header files currently missing it 2016-01-23 11:53:05 +01:00
practicalswift
1339b5403b Consistent use of header comment format.
Correct format:
//===--- Name of file - Description ----------------------------*- Lang -*-===//
2016-01-04 13:26:31 +01:00
practicalswift
50baf2e53b Use consistent formatting in top of file headers. 2016-01-04 02:17:48 +01:00
Zach Panzarino
e3a4147ac9 Update copyright date 2015-12-31 23:28:40 +00:00
Doug Gregor
b8995b0aa3 Transform the Module class into ModuleDecl.
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
2015-05-07 21:10:50 +00:00
Jordan Rose
c90cd11aff [PrintAsObjC] Only include internal decls if we have a bridging header.
The upshot of this is that internal decls in an app target will be in the
generated header but internal decls in a framework target will not. This
is important since the generated header is part of a framework's public
interface. Users always have the option to add members via category to an
internal framework type they need to use from Objective-C, or to write the
@interface themselves if the entire type is missing. Only internal protocols
are left out by this.

The presence of the bridging header isn't a /perfect/ way to decide this,
but it's close enough. In an app target without a bridging header, it's
unlikely that there will be ObjC sources depending on the generated header.

Swift SVN r19763
2014-07-09 23:58:57 +00:00
Jordan Rose
03eacc2931 [PrintAsObjC] Forward-declare things for the generated header when possible...
...and just outright import the bridging header if that's what's needed.

This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.

<rdar://problem/17183425>

Swift SVN r18795
2014-06-11 00:01:58 +00:00
Jordan Rose
95461797aa Move -print-as-objc feature into a library.
No functionality change.

Swift SVN r13798
2014-02-12 01:19:09 +00:00