In these cases, disable the standard system include paths so we don't
accidentally pick up headers in /.
This is going to be used by the runtime team for low-level interfaces with
C and Objective-C in the standard library.
Swift SVN r14789
This reverts part of r14563, which swapped out the mirroring of
Objective-C initializers into subclasses. We still need to do this
when a subclass does not declare it's designated initializers. At
least the mirroring code is more robust, and marks declarations as
implicit so they won't show up when printed.
Swift SVN r14633
Make Objective-C initializers inherited according to the inheritance
rules we've specified. Prevent the Clang importer from manually
copying all of the initializers from every superclass into each
class.
This eliminates a ton of extra allocating constructors generated when
importing Objective-C init methods. Now we only generate allocating
constructors for the init methods that are actually declared.
Note that initializer inheritance only actually works for
Objective-C-defined classes. More to come.
Swift SVN r14563
There are two parts to this:
- Import protocol properties as properties, instead of as a pair of methods.
- Fix IRGen to handle property accesses in @objc protocols.
<rdar://problem/12993073>
Swift SVN r14438
This is hidden behind the frontend flag -enable-objc-optional. Use -Xfrontend
when invoking the Swift driver.
Part of <rdar://problem/15189135>
Swift SVN r14332
We will still import these as just 'Int', 'UInt', etc., but we still want to
allow users to write some of these types themselves. We now have an enum field
in MappedTypes.def to control this.
Fix-up for r14069 and <rdar://problem/16067854>
Swift SVN r14105
...rather than Int.
This handles the case where there are existing 32-bit enum constants with
the bit set, which isn't that uncommon for NS_OPTIONS declarations.
Part of <rdar://problem/15368372>, but should also fix the main issue in
<rdar://problem/15236662>.
Swift SVN r14090
This is more in line with all other modules currently on our system.
If/when we get our final name for the language, we're at least now set
up to rename the library without /too/ much trouble. (This is mostly just
a lot of searching for "import swift", "swift.", "'swift'", and '"swift"'.
The compiler itself is pretty much just using STDLIB_NAME consistently now,
per r13758.)
<rdar://problem/15972383>
Swift SVN r14001
This is necessary on 32-bit arm, where va_list's canonical type is void*.
Without a typedef-based mapping the importer would drop declarations used
by the NSStringAPI bridge because they appear to have void* parameters.
This mapping does not work on x86_64. SwiftTypeConverter::VisitTypedefType()
never sees va_list on that architecture only, perhaps due to that
architecture's unusual definition of __builtin_va_list. The default mapping
to COpaquePointer plus the conversion CVaListPointer=>COpaquePointer
is still in place for that architecture.
Swift SVN r12853
This still isn't /that/ lazy because a lot of things can force member
deserialization (such as the type-checker generating a DestructorDecl for
every imported class), and we don't do this in a member-granular way just
yet. I don't see any change in testing time, for example.
But besides just being a good thing in general, this perturbs the order
of imported decls enough to fix <rdar://problem/15799697>: we can now
reliably see that there is a -URL:something: function on NSObject that
blocks any properties named 'URL' from being imported as properties.
(Which we don't actually want; see <rdar://problem/15456130>.)
Swift SVN r12685
Hardcoding a path to a particular SDK is definitely the wrong thing to do.
Let's see how far we can get without setting a default SDK.
See discussion in <rdar://problem/14395800>
Swift SVN r12414
This can happen when importing a decl causes a new Swift module to be loaded
(because it uses one of our bridged types), which then brings in a new Clang
module. In this case we have no choice but to throw out the existing cache
and start over. We do keep a map of everything we've imported already, though,
so at least we don't have to do that part again.
This appears to make r12309 unnecessary for correctness, but it probably still
makes performance more consistent.
<rdar://problem/15785883>
Swift SVN r12336
-respondsToSelector: is declared on the NSObject protocol, which is adopted
by the NSObject root class. The NSObject metaclass also extends NSObject,
so it also needs a respondsToSelector:. This effectively becomes a
+respondsToSelector: method on NSObject-the-class.
Change importMirroredProtocolMembers to actually do this, just like
importObjCMembers was changed in r11614 for instance methods declared
directly within the class.
Finishes <rdar://problem/13371711>.
Swift SVN r11881
Not only this creates less ASTs, but this makes the resulting AST correct (it
is invalid to have a struct and a typealias with the same name). But the
primary motivation is AST pretty-printing: we don't want to print those extra
useless typealiases.
Swift SVN r11289
Now that everything is done in terms of FileUnits, we don't need LoadedModule
anymore, and now that FileUnits just use virtual dispatch, we don't need to
indirect through ModuleLoader to distinguish them.
This doesn't quite simplify as much as it could, because the next change is
going to combine TranslationUnit and Module.
Swift SVN r10836
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Apply the same prefix-chopping logic as for NS_ENUM to produce static property names to put inside the Swift type we create. For now, continue importing NS_OPTIONS as structs with a single integer field; in the short term it's easy to put a C-like interface over them this way.
Swift SVN r10434
Swift enums don't yet support aliasing of enum cases, so if we see multiple constants in an NS_ENUM with the same underlying value, drop all but the first. Hopefully the first one is the "proper" name for the constant.
Swift SVN r10008
Swift enum cases are already namespaced to their type, but Cocoa NS_ENUM constants are manually namespaced with a common prefix, so if we imported them as-is, we'd end up with expressions like 'NSStringSearchOptions.NSStringSearchCaseSensitive'. To make this a bit nicer, look for a common prefix of camel-case words among all of the constants in the enum, and remove that prefix from the enum case names in the Swift interface.
In the case of a single enum case, we have no basis for determining a prefix, so do nothing. This case doesn't come up in the frameworks (that I can see).
Swift SVN r9993
NSDictionary's implementation of -objectForKeyedSubscript: takes an id
instead of 'id <NSCopying>' because a dictionary could in theory have non-
copyable keys. However, Swift requires the getter and setter for a subscript
operator to have the same type. Therefore, we unilaterally import the
getter as 'subscript(key : NSCopyingProto) { get }', and just rely on the
fact that the representation of 'id' and 'id <NSCopying>' is the same.
What doesn't change:
- objectForKey() still takes a plain 'id', in the rare cases that that is
useful.
- Looping over an NSDictionary still gives you (id, id) pairs, on the grounds
that if you actually want to do something with the key, it probably isn't
going to be copying it. Without this, doing something useful with the key
would require an explicit cast.
- If any other subscript indexes don't match up, the subscript is dropped
(r8636).
<rdar://problem/14397360>
Swift SVN r9424
If Foundation wasn't ever actually loaded into the ASTContext, type
lowering would fail to find the NSString-to-String conversion functions.
Fix this by only bridging NSString when a module named "Foundation" can
be loaded.
This still isn't very precise, since the bridging functions could still
be missing, but it at least avoids a user-triggerable error.
<rdar://problem/15027448>
Swift SVN r9380
docs/Resilience.rst describes the notion of a resilience component:
if the current source file is in the same component as a module being
used, it can use fragile access for everything in the other module,
with the assumption that everything in a component will always be
recompiled together.
However, nothing is actually using this today, and the interface we
have is probably not what we'll want in 2.0, when we actually implement
resilience.
Swift SVN r9174
Argument patterns create pseudo-named patterns, so make them implicit and ignore them when scanning for explicit source information.
Also make sure that the clang importer sets the HasSelectorStyleSignature bit appropriately.
Swift SVN r8803
Loading Cocoa (Clang) triggers the loading of several other modules,
including Foundation (Clang). We want to make sure we bring in the adapter
module Foundation (Swift), so loading Cocoa currently triggers a walk of
all imported modules to check for an adapter. The problem is that
Foundation (Swift) contains some eagerly-deserialized decls, which refer
to decls in Foundation (Clang). These decls were not importing correctly
because we hadn't finished loading all the adapters -- specifically, we
hadn't yet loaded ObjectiveC (Swift). This meant SEL was loaded as
swift.COpaquePointer instead of ObjectiveC.ObjCSel.
Now, when Foundation (Swift) asks to load Foundation (Clang), we'll walk
all imported modules under Foundation (Clang) to check for an adapter
before returning, even if Foundation (Clang) is already in our system.
This probably still isn't the best way to deal with this (particularly
since the modules in the subtree will get visited twice), but it ensures
that we've loaded all necessary adapter modules before trying to import
any decls.
TLDR: Importing Cocoa now correctly imports the Swift overlay for the
ObjectiveC module, meaning SELs are correctly imported.
<rdar://problem/14759044>
Swift SVN r7293
Before this change, DeclContext of all imported decls was set to the first
imported module.
No tests now, will be tested by future code completion commits.
Swift SVN r6949
We haven't fully updated references to union cases, and enums still are not
their own thing yet, but "oneof" is gone. Long live "union"!
Swift SVN r6783
This handles both Clang’s transitive inclusion and the use of
"adapter modules" to augment the Clang modules (e.g. Foundation.swift),
at the cost of a bit more memory (used to wrap all the Clang modules
in ClangModule objects). This is paving the way for making Sema
independent of ClangImporter.
Swift SVN r6698
This makes it very clear who is depending on special behavior at the
module level. Doing isa<ClangModule> now requires a header import; anything
more requires actually linking against the ClangImporter library.
If the current source file really can't import ClangModule.h, it can
still fall back to checking against the DeclContext's getContextKind()
(and indeed AST currently does in a few places).
Swift SVN r6695
binary compatible.
This enables us to import MacTypes.h types as stdlib swift types to avoid name
conflicts. We also import stdint.h types as stdlib swift types.
We can not map 'long double'-based ctypes.Float80 to swift.Float80 because size
of long double is 128 according to SysV ABI, and I compare that against what
the type name says (I did not find a way to find the size of the type).
Darwin.Float80 is a struct, so I don’t think we can import it as swift.Float80.
So with import Darwin, Float80 is still ambiguous.
I had to rename test/ClangModules/ctypes.swift ->
test/ClangModules/ctypes_test.swift because other tests do 'import ctypes',
which picks up 'ctypes.swift'.
Swift SVN r5727
implemented pointer arithmetic. Enhanced UnsafePointer<T> to do pointer
arithmetic.
Also: update Clang importer to import T* as UsafePointer<T>, fix standard
library fallout.
Swift SVN r5616
We had an inconsistency where the synthesized Swift getter/setters were bridged but the VarDecl wasn't, causing assertion failures in SILGen.
Swift SVN r5366
The importer has always imported types differently in different
places, e.g., function parameter types have special rules for C++
references. Formalize this notion a bit, and make it work properly
when dealing with typedefs where the underlying type itself might be
imported differently in different contexts.
As part of this, limit the import of C's 'void' type to the result of
a function type.
Swift SVN r5055
