Until now, only indirect fields that didn't belong to a C union (somewhere
between the field declaration and the type in which it is indirectly
exposed) were imported in swift. This patch tries to provide an approach
that allows all those fields to be exposed in swift. However, the downside
is that we introduce new intermediate fields and types, some of the fields
may already have been manually defined in type extension (as seen with the
GLKit overlay).
The main idea here is that we can simply expose the anonymous
struct/unions from which the indirect types are taken and then use swift
computed properties to access the content of those anonymous
struct/unions. As a consequence, each time we encounter an anonymous
struct or union, we actually expose it at __Anonymous_field<id> (where id
is the index of the field in the structure). At this point, we use the
existing mechanism to expose the type as
__Unnamed_<struct|union>_<fieldname>. Then, each indirect field is exposed
as a computed property.
The C object:
typedef union foo_t {
struct {
int a;
int b;
};
int c;
} foo_t;
Is imported as
struct foo_t {
struct __Unnamed_struct___Anonymous_field1 {
var a : Int32
var b : Int32
}
var __Anonymous_field1 : foo_t.__Unnamed_struct___Anonymous_field1
var a : Int32 {
get {
return __Anonymous_field1.a
}
set(newValue) {
__Anonymous_field1.a = newValue
}
}
var b : Int32 {
get {
return __Anonymous_field1.b
}
set(newValue) {
__Anonymous_field1.b = newValue
}
}
var c : Int32
}
This has the advantage to work for both struct and union, even in case we
have several nested anonymous struct/unions. This does not require to know
the size and/or the offset of the fields in the structures and thus can be
properly implemented using front-end data.
Signed-off-by: Florent Bruneau <florent.bruneau@intersec.com>
* replace unused closure parameters with '_' in stdlib source
* fold some _ closure arguments into line above
* fold more _ closure arguments into line above
Apple and the Swift community has settled on this style:
https://devforums.apple.com/message/1133616#1133616
> FWIW, we've recently decided to standardize on () -> Void
> (generally, () for parameters and Void for return types) across all of our
> documentation.
Swift 3 unintentionally allowed collection casts from, e.g.,
Set<AnyHashable> to Set<NSObject>, when in fact the object
representation of the AnyHashable might not be an NSObject. Fix up our
tests and overlays that ran afoul of this rule.
