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
