SE-0364 was implemented to discourage "retroactive" conformances that might
conflict with conformances that could be introduced by other modules in the
future. These diagnostics should not apply to conformances that involve types
and protocols imported from the underlying clang module of a Swift module since
the two modules are assumed to be developed in tandem by the same owners,
despite technically being separate modules from the perspective of the
compiler.
The diagnostics implemented in https://github.com/apple/swift/pull/36068 were
designed to take underlying clang modules into account. However, the
implementation assumed that `ModuleDecl::getUnderlyingModuleIfOverlay()` would
behave as expected when called on the Swift module being compiled.
Unfortunately, it would always return `nullptr` and thus conformances involving
the underlying clang module are being diagnosed unexpectedly.
The fix is to make `ModuleDecl::getUnderlyingModuleIfOverlay()` behave as
expected when it is made up of `SourceFile`s.
Resolves rdar://121478556
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
NSObject.hashValue is provided to satisfy the hashValue constraint of
the Hashable protocol. However, it is not the correct customization
point for interoperating with Objective-C, because Objective-C code
will call through the -hash method. Warn about overrides of
NSObject.hashValue; users should override NSObject.hash instead.
Fixes rdar://problem/42780635.
change includes both the necessary protocol updates and the deprecation
warnings
suitable for migration. A future patch will remove the renamings and
make this
a hard error.
Implements SE-0055: https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md
- Add NULL as an extra inhabitant of Builtin.RawPointer (currently
hardcoded to 0 rather than being target-dependent).
- Import non-object pointers as Optional/IUO when nullable/null_unspecified
(like everything else).
- Change the type checker's *-to-pointer conversions to handle a layer of
optional.
- Use 'AutoreleasingUnsafeMutablePointer<NSError?>?' as the type of error
parameters exported to Objective-C.
- Drop NilLiteralConvertible conformance for all pointer types.
- Update the standard library and then all the tests.
I've decided to leave this commit only updating existing tests; any new
tests will come in the following commits. (That may mean some additional
implementation work to follow.)
The other major piece that's missing here is migration. I'm hoping we get
a lot of that with Swift 1.1's work for optional object references, but
I still need to investigate.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
The preferred way to create a nil pointer is to use the 'nil' literal.
Affected types:
AutoreleasingUnsafeMutablePointer
OpaquePointer
UnsafeMutablePointer
UnsafePointer
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
Depends on a clang change to target info, and an objc4 change to the
Objective-C headers, which accomplish the actual ABI change for Swift.Bool.
This commit updates ObjCBool and adds a test.
rdar://problem/21294221
Patch by Ben Langmuir.
Swift SVN r29423
target. Update IRGen/abitypes.swift for TVOS x86_64, arm64 targets.
<rdar://problem/20546299> Difference in ABI re ObjC bools between TVOS
sim and iOS sim?
Swift SVN r28575
While Foundation actually defines the NSZone typedef and what you can do with
it, the ObjectiveC module makes use of it in its raw form: "struct _NSZone *".
To avoid a circular dependency, sink our adapter down to the ObjectiveC
overlay.
Swift SVN r21827
This allows UnicodeScalars to be constructed from an integer, rather
then from a string. Not only this avoids an unnecessary memory
allocation (!) when creating a UnicodeScalar, this also allows the
compiler to statically check that the string contains a single scalar
value (in the same way the compiler checks that Character contains only
a single extended grapheme cluster).
rdar://17966622
Swift SVN r21198
Mechanically add "Type" to the end of any protocol names that don't end
in "Type," "ible," or "able." Also, drop "Type" from the end of any
associated type names, except for those of the *LiteralConvertible
protocols.
There are obvious improvements to make in some of these names, which can
be handled with separate commits.
Fixes <rdar://problem/17165920> Protocols `Integer` etc should get
uglier names.
Swift SVN r19883
Introduce the new BooleanLiteralConvertible protocol for Boolean
literals. Take "true" and "false" as real keywords (which is most of the
reason for the testsuite churn). Make Bool BooleanLiteralConvertible
and the default Boolean literal type, and ObjCBool
BooleanLiteralConvertible. Fixes <rdar://problem/17405310> and the
recent regression that made ObjCBool not work with true/false.
Swift SVN r19728
There is some follow-up work remaining:
- test/stdlib/UnicodeTrie test kills the type checker without manual type annotations. <rdar://problem/17539704>
- test/Sema/availability test raises a type error on 'a: String == nil', which we want, but probably not as a side effect of string-to-pointer conversions. I'll fix this next.
Swift SVN r19477
In most cases this means adding @public to things that get serialized;
in a few cases it means using a modern public stdlib API instead of
a legacy thing I was trying to keep @internal.
Swift SVN r19350
This change moves the swift overlay modules from Clang importer mock sdk to a
central location. (Otherwise we try to deserialize the Foundation overlay for
the system framework, and crash because we don't find all declarations in
our mock sdk.)
Swift SVN r11297
