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
Unfortunately, we're replacing that hack with a different hack to work
around the complete lack of mapping from Swift source locations to
Clang source locations.
Swift SVN r4460
r4035 introduced overridden-method searches into the Clang importer by
looking into the Swift declarations. However, because Objective-C
allows forward declarations, there's no order in which we could
populate the Swift declarations to ensure that all of the appropriate
overrides were found. Instead, we do the right (and lazy) thing of
performing the lookup within Clang, then importing the results. This
change also introduces caching for mirrored protocol imports, so they
can be imported lazily.
Fixes <rdar://problem/13219096>.
Swift SVN r4072
Import C enumeration types as either structs wrapping the underlying
integral type (when the C enumeration type has a name) or as the
underlying integral type (when the C enumeration type has no
name). The structs have a constructor from the underlying integral
type, so one can write, e.g., NSStringCompareOptions(0) to get a
zero-valued enumeration.
Enumerators are imported as a global read-only properties.
Once oneofs start to work, we'll have a way to map some enumeration
types to oneofs, either via a Clang attribute or by sniffing out
NS_ENUM (most likely both).
Once we have static data members of structs working, we'll replace the
global constants with prefix-stripped static variables within the
struct, so we can use ".foo" notation with them.
Once we have constant declarations, we'll map to those instead of
properties.
We can add |, &, and ~ operations are part of
<rdar://problem/13028799> and have not yet been implemented.
Fixes <rdar://problem/13028891>.
Swift SVN r3945
When doing name lookup into a Clang module, look for a macro with the given name and try to convert it into a Swift decl. Turn simple literal macros with expansions <number>, -<number>, or (-<number>) into Swift read-only properties. Map integer literals to Swift 'Int' and float literals to Swift 'Double' for want of a better type to map them to--it would probably be better if we had a decl that behaved like Pascal 'const' and converted like a literal value. Codegen for the synthesized properties isn't wired up, so compiling code that tries to use macro values will currently die because of missing externals.
Swift SVN r3941
When we import an Objective-C protocol, we add the "Proto" suffix to
the name to avoid collisions when a class and protocol have the same
name. Of course, one's "Proto"-suffixed declarations will still
conflict, so this rule isn't great.
Swift SVN r3642
This commit covers only the AST-building side of indexed
subscripting, mapping objectAtIndexedSubscript: and
setObject:atIndexedSubscript: to Swift 'subscript' declarations. IR
generation and support for keyed subscripting to follow.
Swift SVN r3377
This is mostly a hack to work around differences between how Swift and
Clang name lookup into modules works. However, it allows us to load
multiple Clang modules into Swift without causing spurious
ambiguities. The generation-based versioning isn't stricly necessary,
since module imports are resolved up front. However, we may eventually
want to speculatively load modules as part of name binding or type
checking, in which case we'd rather not have stale caches. And it
costs us very little.
Swift SVN r3269
Objective-C's 'id' is a very odd type, because it effectively acts as
both a "top" and a "bottom" for the lattice of Objective-C types,
where "top" is a type everything is a subtype of an "bottom" is a type
everything is a supertype of. We almost surely don't want the "bottom"
behavior in Swift, but we also don't have a suitable notion of "top"
yet. protocol<> is closest, but that's too general because it also
allows value types. NSObject is the closest thing we have, for now, so
we use it.
Swift SVN r3260
There is no protection whatsoever if the Clang-to-Swift type
conversion produces something that Swift doesn't lower in an
ABI-compatible way. That will be dealt with later.
Swift SVN r3249
This importer handles all of the Clang structural types, e.g., builtin
types (int, float, void), function types, block pointer types, and
C pointer types. It does not yet handle nominal types such as enums,
structs, or Objective-C classes, and there are some questions about
(e.g.) array types.
Swift SVN r3212
