This pattern isn't too uncommon:
typedef CF_ENUM(CFIndex, CFFoo) {
CFFooBar
};
typedef NS_ENUM(NSInteger, NSFoo) {
NSFooBar = CFFooBar
};
NSFoo and CFFoo are distinct types, but sometimes you need to convert from
one to the other. Today the only way to do to that is via rawValue, which
is especially unpleasant if the raw types don't match.
This commit introduces a new converting initializer for NSFoo:
init!(_ value: CFFoo) {
self.init(rawValue: RawType(value.rawValue))
}
It's failable by necessity because init(rawValue:) is failable for proper
enums. In practice an audit of our public headers found zero cases where
there are "more" cases in CFFoo than in NSFoo, i.e. cases where the
conversion would fail.
This also applies to option sets and opaque enums, but those use a
non-failable initializer because there's no way to check validity.
rdar://problem/19667625
Swift SVN r25401
This renames their 'value' field to 'rawValue'.
This is needed for consistency in the next commit. I can't find a Radar for
it, though.
Swift SVN r25399
It doesn't make sense to try to construct a partially-imported struct elementwise in Swift. We don't know what all the fields are yet. Part of rdar://problem/19807099.
Swift SVN r25366
Remove the logic that allowed an extension to provide an Objective-C
method that was already declared in the class itself, relying on the
existing Objective-C method redeclaration logic to detect such
conflicts. Fixes rdar://problem/17687082.
Swift SVN r25175
This way, we don't have issues with the verifier bringing in new types and
then those new types having members with un-type-checked bodies. Also,
delaying this is probably future goodness anyway, when we can skip the work
entirely if it's not needed.
I can't come up with a test case that currently fails besides the project in
rdar://problem/19778991, but all existing tests pass.
Swift SVN r25166
We certainly can't import them as stored properties, and it's too late to try to bridge them as computed property, so restore the old behavior of importing them as unbridged object types. The types still come in as strong managed reference types, which is still wrong, but seems to be right enough for Khan Academy and potentially other existing apps for now, and I don't want to introduce additional source-breaking changes and instability this late in the game. Fixes rdar://problem/19789023, leaving rdar://problem/19790608 to be done when we can afford more churn.
Swift SVN r25158
This commit changes the clang importer to always import attributes on property accessors.
Previously, attributes were only imported if the accessor method was declared before the
property but not if the accessor method was declared after it.
Swift SVN r25018
attribute or appear in a whitelist.
The initial whitelist is based on an audit I performed of our current
public SDKs. If there are CF types which appear only in our internal
SDKs, and somebody urgently needs to use them from Swift, they can
adopt the bridging attributes. The goal is to eventually eliminate
the whitelist and rely solely on bridging attributes anyway.
Sadly, CoreCooling was not included in my SDK audit and must be
explicitly annotated. :(
I've left the main database organized by framework, but I wanted
a quasi-lexicographically sorted version to permit efficient lookup.
We generate that copy automatically with gyb. I ended up having
to tweak handle_gyb_sources to allow it to drop the result in
CMAKE_CURRENT_BINARY_DIR instead of CMAKE_CURRENT_BINARY_DIR/{4,8}
if an architecture is not provided. I think this is abstractly
reasonable for generated includes, which have independent ability
to detect the target word size. But just between you and me,
I did it because I couldn't figure out how to add
"-I${CMAKE_CURRENT_BINARY_DIR/{4,8}" as a compile flag;
the obvious thing didn't work. Anyway, I'd appreciate it if
someone double-checked my cmake hackery here.
Swift SVN r24850
If a property, method, or subscript overrides an imported property, method,
or subscript that was originally declared using NSUInteger as a property,
parameter, or return type, print the subclass's member using "NSUInteger"
in the generated header to prevent override warnings.
This doesn't handle all cases--in particular, it doesn't handle the
NSUInteger being nested inside a larger type--but it does get the easy
ones correct. I think the easiest way to be more correct would be to mark
NSUInteger-as-Int somehow using a distinct type. (Hidden attribute?
Another typealias? Not sure.)
rdar://problem/19321126
Swift SVN r24771
...rather, over implicit decls mirrored from protocols into other categories
or the main @interface. But only in the same module, to try to minimize
differences.
rdar://problem/19398912
Swift SVN r24627
Previously the "as" keyword could either represent coercion or or forced
downcasting. This change separates the two notions. "as" now only means
type conversion, while the new "as!" operator is used to perform forced
downcasting. If a program uses "as" where "as!" is called for, we emit a
diagnostic and fixit.
Internally, this change removes the UnresolvedCheckedCastExpr class, in
favor of directly instantiating CoerceExpr when parsing the "as"
operator, and ForcedCheckedCastExpr when parsing the "as!" operator.
Swift SVN r24253
Previously we'd try to put the same method into the list of members multiple
times--once for each redeclaration in the @interface. This led to an
assertion failure.
Checking the canonical decl isn't super cheap, but the ObjCMethodDecl
redeclaration infrastructure seems to be fairly broken. We can revisit this
later.
There's also a test for what happens when categories get involved. I'm not
convinced this is correct behavior, either, and will file an additional bug
to look into that at some point.
rdar://problem/19039485
Swift SVN r24129
We were skipping this step, which meant that the initializers weren't
getting the availability information from their factory methods.
rdar://problem/18323494
Swift SVN r24034
"private" is a very overloaded term already. "Cascading" instead of
"non-private" is a bit more clear about what will happen with this sort
of lookup.
No functionality change. There are some double negatives I plan to clean
up in the next commit, but this one was supposed to be very mechanical.
Swift SVN r23969
If the common prefix of all enumerators ends with an underscore, but the
enumerators don't have a common prefix with the enum itself, we can't
drop the underscore.
rdar://problem/18730653
Swift SVN r23941
We were losing the nullability of factory methods that turned into
initializers (which should have been mapped to failability), and more
generally, methods with nullability for related result types
(instancetype in Clang, dynamic Self in Swift).
Note that this commit also contains tests for a similar Clang-side fix
where Clang itself wasn't correctly recording that an Objective-C
method with a nullability-qualified instancetype result type in fact
had a related result type.
Found by browsing through the most excellent Swift SDK Analyzer.
Swift SVN r23834
We can't reliably reject raw values in an NS_ENUM's init(rawValue:), because the enum may have SPI or future values we don't statically know about. Fixes https://twitter.com/autorelease/status/524698585406124033
Swift SVN r23817
If an imported C struct has no __nonnull pointer fields, then we can give a default initializer that zeroes all of its fields. This becomes a requirement when working with partially-imported types like NSDecimal. NSDecimal has bitfields Swift can't see yet, so it's impossible to DI, but the Foundation functions that work with NSDecimal all emit their result by out parameter, and without access to its fields it is impossible to initialize an NSDecimal for use with one of these functions. Implement the initializer using a builtin that gets lowered by IRGen; this is also made necessary by the fact that Swift has only a partial view of the struct, so we can't form a complete zero initializer until we have the definitive type layout from Clang.
Swift SVN r23727
...and thus does not affect downstream files...
...and adopt it in several places:
- when looking up the default type for a literal (test included)
- when looking up the first component in an IdentTypeRepr (test included)
- when deciding which ~= to use in a switch (test forthcoming)
- when a protocol has an operator function requirement (test forthcoming)
- when validating @NSApplicationMain and @UIApplicationMain
- when an enum element shows up unqualified in a switch
- several places where it doesn't matter because we're looking something up
in the standard library.
Part of rdar://problem/15353101
Swift SVN r23670
Specifically, a qualified lookup can now be treated as:
- a known private dependency, which does not affect downstream files
- a known non-private dependency, which may affect downstream files
- a known non-dependency
- unknown, which means the compiler will try to infer whether it's a
private dependency from the context
This commit also includes some obvious uses of the new flags, but nothing
actually too interesting yet; there shouldn't be any observable behavior
change here in normal user code.
Swift SVN r23483
Have them fill out a vector provided by the caller instead.
It is very easy to have callers just go through the array, thus wasting memory, as
the clang importer ended up doing.
The caller should be the one deciding if the array must be copied in ASTContext or not.
Swift SVN r23472
Thanks Jordan for pointing out that the test didn't in fact test that we imported ObjC-ified Swift decls back to the same type. Adjust things so that we do, putting the annotation attribute in the right place, and fixing a crash when we have superfluous typedefs for native Swift decls.
Swift SVN r23439
This functionality doesn’t really change what we accept right now, because we eagerly import all of the methods of a class when we do *any* kind of lookup into the class. However, when we manage to stop doing that, this operation will become more important.
Swift SVN r23289
Diagnose cases where the use of @objc will produce Objective-C methods
that end up overriding an Objective-C method in a superclass, when
that override is not properly represented as an override in the Swift
type system. This can happen when the Objective-C methods are produced
by different kinds of entities. For example:
class Super {
@objc var property: Int
}
class Sub : Super {
@objc func setProperty(property: Int) { }
}
In Swift, Sub.setProperty and Super.property are completely
unrelated. However, both produce an Objective-C instance method with
the selector "setProperty:", so we end up with unexpected overriding
behavior. Diagnose this whenever it occurs, regardless of the kind of
@objc entity that produced the Objective-C methods: initializers,
deinitializers, methods, properties, or subscripts.
Implements the rest of the intended functionality of
rdar://problem/18391046, with the caveat that there are two remaining
classes of bugs:
1) Superclasses defined in a module (or imported from a Clang
module) aren't handled properly yet; we might not see those methods.
2) We won't properly detect all of these failures when the methods
are scattered across different source files in the same module.
Swift SVN r23170
@objc methods, initializers, deinitializers, properties, and
subscripts all produce Objective-C methods. Diagnose cases where two
such entities (which may be of different kinds) produce the same
Objective-C method in the same class.
As a special exception, one can have an Objective-C method in an
extension that conflicts with an Objective-C method in the original
class definition, so long as the original class definition is from a
different model. This reflects the reality in Objective-C that the
category definition wins over the original definition, and is used in
at least one overlay (SpriteKit).
This is the first part of rdar://problem/18391046; the second part
involves checking that overrides are sane.
Swift SVN r23147
properties.
The main design change here is that, rather than having
purportedly orthogonal storage kinds and has-addressor
bits, I've merged them into an exhaustive enum of the
possibilities. I've also split the observing storage kind
into stored-observing and inherited-observing cases, which
is possible to do in the parser because the latter are
always marked 'override' and the former aren't. This
should lead to much better consideration for inheriting
observers, which were otherwise very easy to forget about.
It also gives us much better recovery when override checking
fails before we can identify the overridden declaration;
previously, we would end up spuriously considering the
override to be a stored property despite the user's
clearly expressed intent.
Swift SVN r22381
There are a lot of different ways to interpret the
"kind" of an access. This enum specifically dictates
the semantic rules for an access: direct-to-storage
and direct-to-accessor accesses may be semantically
different from ordinary accesses, e.g. if there are
observers or overrides.
Swift SVN r22290
When performing name lookup for a declaration that is being called,
use the argument labels at the call site to filter out those
declarations with incompatible argument labels.
Swift SVN r22176
Removes the initWithBool: hack from the Clang importer. We can now
express NSNumber's conformance to the BooleanLiteralConvertible
protocol in the overlay.
Swift SVN r21976
Conforming to BooleanLiteralConvertible now requires
init(booleanLiteral: Bool)
rather than
static func convertFromBooleanLiteral(value: Bool) -> Self
This posed a problem for NSNumber's conformance to
BooleanLiteralConvertible. A class needs a required initializer to
satisfy an initializer requirement, but one cannot add a required
initializer via an extension. To that end, we hack the Clang importer
to import NSNumber's initWithBool with the name
init(booleanLiteral:)
and add back the expected init(bool:) initializer in the
overlay. These tricks make NSNumber even harder to subclass, but we
don't really care: it's nearly impossible to do well anyway, and is
generally a Bad Idea.
Part of rdar://problem/18154091.
Swift SVN r21961
