When attempting to compile Swift 2 code (or any Swift code using the
Swift 2 names) in Swift 3, the compiler diagnostics are often entirely
useless because the names have changed radically enough that one
generally gets "no member named 'foo'" errors rather than a helpful
"'foo' was renamed to 'bar'" error. This makes for a very poor user
experience when (e.g.) trying to move Swift 2 code forward to Swift 3.
To improve the experience, when the Swift 2 and Swift 3 names of an
API differ, the Clang importer will produce a "stub" declaration that
matches the Swift 2 API. That stub will be marked with a synthesized
attribute
@available(unavailable, renamed: "the-swift-3-name")
that enables better diagnostics (e.g., "'foo' is unavailable: renamed
to 'bar') along with Fix-Its (courtesy of @jrose-apple's recent work)
that fix the Swift 2 code to compile in Swift 3.
This change addresses much of rdar://problem/25309323 (concerning QoI
of Swift 2 code compiled with a Swift 3 compiler), but some cleanup
remains.
...when renaming C functions. This is currently rejected by Clang
itself, but showed up when testing apinotes. Rather than complicate
the apinotes by including parameter placeholders, just do the
obvious thing (and future-proof against us potentially allowing this
in the future).
rdar://problem/26133744
This is a squash of the following commits:
* [SE-0054] Import function pointer arg, return types, typedefs as optional
IUOs are only allowed on function decl arguments and return types, so
don't import typedefs or function pointer args or return types as IUO.
* [SE-0054] Only allow IUOs in function arg and result type.
When validating a TypeRepr, raise a diagnostic if an IUO is found
anywhere other thn the top level or as a function parameter or return
tpye.
* [SE-0054] Disable inference of IUOs by default
When considering a constraint of the form '$T1 is convertible to T!',
generate potential bindings 'T' and 'T?' for $T1, but not 'T!'. This
prevents variables without explicit type information from ending up with
IUO type. It also prevents implicit instantiation of functions and types
with IUO type arguments.
* [SE-0054] Remove the -disable-infer-iuos flag.
* Add nonnull annotations to ObjectiveCTests.h in benchmark suite.
For swift_newtype structs that we create, we sometimes need to provide
a bridged type interface. In these cases, we use the original
non-bridged type as an underlying stored value, and create a computed
rawValue of bridged type. We similarly create an init() taking the
bridged type, and cast it appropriately to/from storage.
Tests updated.
The Clang importer implicitly synthesizes @discardableResult for
nearly all imported functions. Printing this attribute in the
generated interface leads to a lot of noise. Mark it as implicit so we
don't print it.
This is a temporary solution that implements swift_newtype(enum) as
though it were written swift_newtype(struct). This is to work around
to the fact that a String-backed enum does not actually have a String
stored, and a struct is closer to reflecting that storage
properly. Struct provides most of the functionality and appearance for
now, though it does not allow for switching over the values.
Full support for swift_newtype(enum) as a Swift enum is forthcoming.
This introduces support for swift_newtype(struct) attribute (also
known as swift_wrapper). The Clang importer will create a brand new
struct corresponding to the annotated typedefs, which has a backing
raw value. Globals of that type are imported as static members on the
struct.
Additionally, this interacts seamlessly with prior import-as-member
work, meaning that the newly created type can be imported onto. Tests
included.
While inferring get/set, we paired them up even when one of them was
available through a custom objc header (e.g. a private
header). Instead, fail to pair them up. Test case added.
Some of the callers to importDeclContextOf could and should have
passed an effective context, but didn't, so (e.g.) an enum defined in
C couldn't be mapped to a nested type in Swift. Eliminate the
single-argument importDeclContextOf honeypot so we remember to pass
down the effective Clang context. Fixes rdar://problem/25502497.
For the most part this was just "check isInstanceProperty"; the one feature not yet implemented
is the emission of ObjC metadata for class properties.
rdar://problem/16830785
When importing members of an NS_OPTIONS (aka an option set), mark imported
members that have a value of 0 with an unavailable error. This produces an
experience like this:
x = NSRuncingOptions.none // expected-error {{'none' is unavailable: use [] to construct an empty option set}}
This is important to do, because option set members with a value of zero
do not act like members of the option set. For example, they always fail a
"contains" check.
This ensures their bodies are fragile in SIL. While they can
be synthesized again, this change will avoid tripping up the
SIL verifier after some upcoming changes.
Part of https://bugs.swift.org/browse/SR-267.
Computes the generic signature correctly for protocol extensions. Sets
the correct function and interface type when forming the imported
protocol member. This makes import-as-protocol-member work and fixes
the disappearing return value issue in protocols.
This was added at some point to make 'import Foundation' faster in the REPL.
What we really care about though is not delaying synthesis of the rawValue
accessors (those are synthesized on demand anyway), but delaying the
conformance check to RawRepresentable.
Moves CFPointeeInfo into CFTypeInfo.h/cpp, so that other parts of the
importer can re-use the logic for reasoning about CF types. This will
be needed by the import as member inference system to reason about
effective Clang contexts.
For function that we are importing as init, if there's dangling words
after the "Create" or "Make", we move them onto the first argument
label. This introduces the creation of an empty tuple parameter when
that init has no arguments.
