It sounds good on paper, but in practice we ended up breaking Core Data
projects (because people name their boolean properties 'isFoo' rather
than the Objective-C 'foo'), forcing an Objective-C-side change when
a mixed-source project upgrades to Swift 3, and causing collisions when
there are properties named both 'foo' and 'isFoo'. If people care about
their Swift boolean properties strictly following the Objective-C Cocoa
naming conventions, they'll have to specify them manually.
(We do have a bug to make it easier to rename the getter of a stored
property exposed to Objective-C: rdar://problem/21261564.)
This reverts commit 6fe6266c99.
rdar://problem/26847223
We're now correctly checking for inheritance, adding @objc methods,
and adding @objc protocols for both CF types and objc_runtime_visible
classes (those without visible symbols). The latter is used for some
of the types in Dispatch, which has exposed some of the classes that
were considered implementation details on past OSs.
We still don't properly implement using 'as?' to check conformance to
a Swift protocol for a CF or objc_runtime_visible type, but we can do
that later.
rdar://problem/26850367
This flag tracks whether we have a special kind of imported class
that has limitations in what you can do with it. Currently it's
used for two things: CF classes, and the magic "Protocol" class used
to represent Objective-C protocol metadata. I'm planning to add a
third to handle classes with the recently-added objc_runtime_visible
attribute, which describes an Objective-C class whose runtime symbols
are hidden (forcibly preventing categories and subclassing). This is
used for some of the types in Dispatch, which has exposed some of the
classes that were considered implementation details on past OSs.
I'm splitting the flag into an enum rather than just marking the
Dispatch classes with the existing flag because we still need to
be able to /cast/ to the Dispatch types (which you can't do with CF
types today) and because they deserve better than to be lumped in
with CF for diagnostic purposes.
Groundwork for rdar://problem/26850367, which is that Swift will
happily let you extend the new Dispatch classes but then fails to find
the symbols at link-time.
Consider this code:
struct A<T> {
struct B {}
struct C<U> {}
}
Previously:
- getDeclaredType() of 'A.B' would give 'A<T>.B'
- getDeclaredTypeInContext() of 'A.B' would give 'A<T>.B'
- getDeclaredType() of 'A.C' would give 'A<T>.C'
- getDeclaredTypeInContext() of 'A.C' would give 'A<T>.C<U>'
This was causing problems for nested generics. Now, with this change,
- getDeclaredType() of 'A.B' gives 'A.B' (*)
- getDeclaredTypeInContext() of 'A.B' gives 'A<T>.B'
- getDeclaredType() of 'A.C' gives 'A.C' (*)
- getDeclaredTypeInContext() of 'A.C' gives 'A<T>.C<U>'
(Differences marked with (*)).
Also, this change makes these accessors fully lazy. Previously,
only getDeclaredTypeInContext() and getDeclaredIterfaceType()
were lazy, whereas getDeclaredType() was built from validateDecl().
Fix a few spots where the return value wasn't being checked
properly.
These functions return ErrorType if a circularity was detected via
the generic parameter list, or if the extension did not resolve.
They return Type() if the extension cannot be resolved *yet*.
This is pretty subtle, and I'll need to do another pass over
callers of these functions at some point. Many of them should be
moved over to use getSelfInContext(), getSelfOfContext() and
getSelfInterfaceType() instead.
Finally, this patch consolidates logic for diagnosting invalid
nesting of types.
The parser had some code for protocols in bad places and bad things
inside protocols, and Sema had several different bail-outs for
bad things in protocols, nested generic types, and stuff nested
inside protocol extensions.
Combine all of these into a single set of checks in Sema. Note
that we no longer give up early if we find invalid nesting.
Leaving decls unvalidated and un-type-checked only leads to
further problems. Now that all the preliminary crap has been
fixed, we can go ahead and start validating these funny nested
decls, actually fixing some crashers in the process.
Every call to validateGenericTypeSignature() had the same
boilerplate following; move the common logic into that
function.
As one might expect, each callsite had slight variants on
the same underlying logic -- this makes them consistent.
Also, this slightly widens the scope during which
GenericTypeDecl::isValidatingGenericSignature() returns
true.
Interesting, that change introduces a diagnostic in an
existing testcase where previously there was none:
protocol P {
associatedtype T
}
struct S<A: P where A.T == S<A>> {}
While it looks like this generic signature was built
correctly, in fact I think we weren't computing
conformances for the substitution of 'A' in 'S<A>'.
After trying small variations on the above testcase,
I quickly ran into SILGen crashes, which the diagnostic
now prevents. A few interesting cases still crash.
See test/decl/protocol/req/recursion.swift for the
gory details.
There was a weirdness with ProtocolType::get() that was causing me grief
while trying to refactor getDeclaredType() and related code in another
patch.
Instead of caching the result like we do elsewhere, this would directly
store the new type into the ProtocolDecl. This is smelly, so let's not
do that.
If a behavior has storage that can be initialized out-of-line, generate code in SILGen that uses stores to mark_uninitialized_behavior for eventual analysis by DI.
This is incomplete, particularly, it's missing code generation of glue thunks for accessors that require reabstraction, but I wanted to make sure the progress here didn't bitrot.
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.
