Previously this would mean something like
class C {
private func f() {}
}
would end up with the symbol for f being completely public (external,
default visibility), even though it only needs to match the internal
class (external, hidden visibility).
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
This handles the case where the left hand side of the cast is known
to be class-like, and the right hand side is known at compile time
to be a protocol composition type.
Note that this change results in a small optimization -- a checked
cast of a metatype known to be a class metatype to a class-constrained
existential metatype no longer has to emit an explicit check that
the source is class-constrained.
Fully dynamic casts are coming up next.
Do the same thing we do for nominal types, where if the type
contains an archetype, just mangle the unbound generic form,
since the name is just for documentation purposes in LLVM IR
dumps and does not have to be unique.
This is tested as part of an upcoming patch.
Enums with the ns_error_domain attribute represent codes for NSError,
which means Swift developers will expect to interact with them in
terms of Error. SE-0112 improved bridging for these enums to generate
a struct with the following form:
struct MyError: Error {
@objc enum Code: RawRepresentable {
case outOfMemory
case fileNotFound
}
var userInfo: [NSObject: AnyObject] { get }
static var outOfMemory: Code { get }
static var fileNotFound: Code { get }
}
where MyError.Code corresponds to the original MyError enum defined in
Objective-C. Until recently, both the enum and the synthesized struct
were marked as having the original enum as their "Clang node", but
that leads to problems: the struct isn't really ObjC-compatible, and
the two decls have the same USR. (The latter had already been worked
around.)
This commit changes the struct to be merely considered a synthesized
"external definition", with no associated Clang node. This meant
auditing everywhere that's looking for a Clang node and seeing which
ones applied to external definitions in general.
There is one regression in quality here: the generated struct is no
longer printed as part of the Swift interface for a header file, since
it's not actually a decl with a corresponding Clang node. The previous
change to AST printing mitigates this a little by at least indicating
that the enum has become a nested "Code" type.
We don't want LLVM aggresively inlining llvm.memcpy instructions and similar
aggressive optimizations to save code size.
For example the X86 target sets max stores per memset to 16 and max stores per
memcpy to 8 (vs 4).
Loop optimizations are also a lot more aggressive.
rdar://31691017
Class-constrained existentials usually have unknown
reference counting in Swift, because they can contain
either Objective-C or native Swift classes.
But if the class existential has a superclass bound
which is known to be an imported Objective-C class,
we can use Objective-C reference counting instead of
unknown reference counting.
This is tested with the next commit that adds
ClangImporter support.
This function has a new argument to specify a DWARFAddressSpace value.
There is a default value but since it was not added as the last argument,
Swift needs to update calls that specify the optional pointer type name
argument.
(cherry picked from commit 21ddc5c087)
(cherry picked from commit 915cda6a05cf7c7eddbb79af14a023914cb9cea9)
It looks like this is really only used in one place, the
"extended encoding" for @objc protocol metadata.
If it wasn't for that, we could just lower all class and
existential types as 'id'.
