This is support for SE-0069: Mutability and Foundation Value Types.
In cases where someone has overridden a method that takes, e.g.
'NSURL', the override will no longer be valid, because the system
class will now use the value type 'URL' instead. If an override's
full name matches exactly, the compiler will offer fix-its for any
uses of reference types where value types are now preferred.
(This must be a direct match; subclasses, including the mutable
variants of many Foundation types, will need to be updated by hand.)
One wrinkle here is the use of generics. In Swift 2, Objective-C
generics weren't imported at all, so it's unlikely that the overriding
method will have the correct generic arguments. Simple migration
might insert the "bound" type, but it can't know what specific type
might be more appropriate. Therefore, the logic to add the fix-it
ignores generic arguments, assuming the parent's type is correct.
rdar://problem/26183575
This is a follow-up to the change that allowed one to omit @objc (or
the name in an @objc) when it can be inferred by matching a
requirement. There is no point in suggesting that one add @objc if it
will be inferred anyway, since it's just syntactic noise.
The fix for methods to lower the dynamic method type from the substituted AST type of the expression also needed to be applied to the optional chaining, subscript, and property paths.
This also exposed a problem in the Clang importer, where imported subscript accessors would get the unbound generic context type as their Self parameter type instead of the type with the correct generic parameters. Fix this by renaming the all-too-convenient ParamDecl::createSelf factory to `createUnboundSelf`, and introduce a new `createSelf` that uses the bound generic type.
Fixes rdar://problem/26447758.
Some ObjC generic APIs rely on covariance, and until we devise a systematic solution for SR-1522, you need to force-cast to get the types to line up in cases like this:
func foo(x: GenericClass<NSMutableString>) {
let x2 = x as! GenericClass<NSString>
takeGenericClassOfNSString(x2)
}
We currently raise a "cast will never succeed" warning, which is wrong because the dynamic cast can't even check the generic parameters. Suppress this warning. Fixes rdar://problem/26398265.
The verifier now asserts that Throws, ThrowsLoc and isBodyThrowing()
match up.
Also, add /*Label=*/ comments where necessary to make the long argument
lists easier to read, and cleaned up some inconsistent naming conventions.
I caught a case where ClangImporter where we were passing in a loc as
StaticLoc instead of FuncLoc, but probably this didn't affect anything.
Previously, we would only reliably propagate conformances from new extensions to immediate subclasses, since when we visit grandchild classes, we'd see no change in the immediate base class's status. Fix this by walking up the entire superclass chain when we look for new inherited conformances, and track the last processed state of different nominal type decls' extensions separately. Fixes SR-1480.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
When an optional requirement of an @objc protocol has a selector that
collides with an entity that has a different *Swift* name but produces
an Objective-C method with the same selector, we have an existing
diagnostic complaining about the conflict. In such cases, make a few
suggestions (with Fix-Its) to improve the experience:
* Change Swift name to match the requirement, adding or modifying the
@objc as appropriate.
* Add "@nonobjc" to silence the diagnostic, explicitly opting out of
matching an @objc requirement.
This is intended to help with migration of Swift 2 code into Swift
3. The Swift 2 code will produce selectors that match Objective-C
methods in the protocol from Swift names that don't match; this helps
fix up those Swift names so that we now match.
Fixes the rest of rdar://problem/25159872. In some sense, it's a
stop-gap for more detailed checking of near-misses for optional
requirements, but it's not clear how wide-reaching such changes would
be.
When a Clang-defined Objective-C class has the objc_runtime_visible
attribute, use objc_lookUpClass to get the Objective-C class object
rather than referencing the symbol directly. Also, ban subclassing of
Objective-C-runtime-visible classes as well as @objc on members of
extensions of such classes.
As a drive-by needed for this test, make
ClassDecl::getObjCRuntimeName() respect the Clang objc_runtime_name
attribute.
Fixes rdar://problem/25494454.
Fix an i32 vs. 64 issue in the IR matching for the IR generation test.
This reverts commit 09973e6956.
When a Clang-defined Objective-C class has the objc_runtime_visible
attribute, use objc_lookUpClass to get the Objective-C class object
rather than referencing the symbol directly. Also, ban subclassing of
Objective-C-runtime-visible classes as well as @objc on members of
extensions of such classes.
As a drive-by needed for this test, make
ClassDecl::getObjCRuntimeName() respect the Clang objc_runtime_name
attribute.
Fixes rdar://problem/25494454.
- Fix ExprTypeSaverAndEraser to save & restore the invalid bit on closure parameter decls.
- Teach CalleeCandidateInfo::evaluateCloseness to not try to find generic subs on types that
contain a unresolved type within them.
With these changes, the compiler doesn't segfault on the testcase when assertions are
enabled. It still doesn't produce a great diagnostic though.
This attribute is a stand-in for the versioning annotations
described in docs/LibraryEvolution.rst; right now it's just present
or absent, and its only effect is to make sure versioned internal
decls are treated as public at the SIL level. (This functionality
already existed for -enable-testing, so it can probably be trusted.)
Also, allow inlineable functions to reference transparent and
inline-always functions /if/ they're only called immediately (not used
as values or partial-applied), since they'll be inlined away before
emitting IR. (We should really only allow this /before/ mandatory
inlining, but we don't have a separate SIL stage for that.)
Let's say I am a good citizen and document my private symbols:
/** My TOP SECRET DOCUMENTATION */
private class Foo {
}
When I go to distribute the compiled binary, I find out my private
documentation is distributed as well:
$ swiftc test.swift -emit-module -module-name "test"
$ strings test.swiftdoc
My TOP SECRET DOCUMENTATION
/** My TOP SECRET DOCUMENTATION */
If a client can't use a symbol (e.g. it's private [or internal and not
-enable-testing]) don't emit the documentation for a symbol in the
swiftdoc.
Fixes: SR-762, rdar://21453624
The test coverage implements this truth table:
| visibility | -enable-testing | documentation? |
|------------|-----------------|----------------|
| private | no | ❌ |
| internal | no | ❌ |
| public | no | ✅ |
| private | yes | ❌ |
| internal | yes | ✅ |
| public | yes | ✅ |
Modified the existing comments test coverage to expect non-public
documentation not to be emitted.
Don't rely on existing comment structure
Refuse to emit comments if the decl cannot actually have one. To
accomplish this, we move `canHaveComment` into the Decl instance. It
must also be marked `const`, since one of its existing usages operates
on a const pointer.
Perform fewer checks when serializing the standard library.
Introduce abstraction patterns for curried C-functions-as-methods for type lowering, and plumb the "foreign self parameter index" through call emission so that we emit the "self" parameter in the right position. This gets us handling C functions imported as methods with explicit swift_name attributes in simple, fully-applied cases. There's still more work to be done for properties, partial applications, and initializers introduced by extensions.
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.
Allow a behavior protocol to declare an `initStorage` implementation with a parameter. If we have an initializer expression, use `initStorage(initExpr)` to initialize the storage; otherwise, remember the storage declaration and its initializer. Definite
initialization will have to use these to insert the initialization operation for the behavior property at the right place.
We had four duplicated implementations of checking how a protocol
requirement uses 'Self', all slightly wrong or incomplete:
- When deciding if the protocol type can be used as an existential.
This one would just ignore 'Self' in the return type of a method
completely, which was incorrect for cases where 'Self' is
contravariant but part of the return value, for example:
func foo() -> (Self -> ())
- When deciding if a member access can be performed on an existential
value. This is distinct from the former, because the member may
have been defined in a protocol extension, in which case it cannot
be used even if the protocol type can be used as an existential.
Unfortunately, this implementation was overly conservative, and
would reject uses of 'Self' where Sema could in fact erase the
existential type, for example:
func foo() -> Self??
func foo() -> Self.Type
func foo() -> (Self, Self)
This function handled function return types correctly, effectively
plugging the leak in the previous code. It did lead to inconsistent
behavior with protocols that had contravariant Self in requirements
though; sometimes we would diagnose uses of the existential type,
other times we would only complain about specific members.
- When deciding if a method in a non-final class can model a protocol
requirement. This one was the most elaborate one, but here
contravariance and uses of associated types are actually okay, so
it was written to pick up covariant 'Self' only. However, it also
did not handle metatypes and tuples.
- When opening the type of member of an existential, we would check
if the return value was 'Self' or an optional of 'Self', but again
this check was too conservative, so after the previous three were
fixed, we could reference members on existentials that did not
have a correct opened type.
Now, these have been combined into one check. To fix some crashes,
Sema's implementation of erasing existentials now relies on
coerceToType() instead of hand-rolling a few coercions of its own,
and wrapping the rest in CovariantFunctionConversionExpr, which
didn't make much sense if the result was not a function type.
SILGen still does not support function type conversions where an
existential return value is being erased; these would silently
miscompile before, but crash with an assertion now, because they
are correctly modeled as a FunctionConversionExpr, and not
CovariantFunctionConversionExpr.
