(currently spelled with an underscore to indicate its WIP state)
Later commits will handle imported enums correctly and implement the
checks for switch cases.
We have a predicate in ClassDecl, 'inheritsSuperclassInitializers',
that is used in a few places to decide if we need to do lookups into a
superclass to find all relevant initializers. That's useful, but the
actual work being computed in that function is almost identical to the
work done in figuring out whether the class has provided all its
superclass's /required/ initializers, which is part of the type
checker operation 'resolveImplicitConstructors'. Furthermore,
'inheritsSuperclassInitializers' is /already/ calling
'resolveImplicitConstructors' because those implicit constructors
might affect the result.
Simplify this whole mess and prevent further inconsistencies like the
previous commit by just making 'resolveImplicitConstructors' decide
whether superclass convenience initializers are inherited. It does
make that function more complicated, but with the benefit of not
having duplication anymore.
No intended user-visible change, except that this bit is now
serialized instead of being recomputed, which means the module format
changed.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
Swift currently assumes that copies and deinitializations of C structs
are always "trivial", i.e. a copy can be done by just copying the raw
bits of the value, and a deinit requires no work at all. Until we do
anything to change that, just don't import any of the new C structs
that have non-trivial copy or deinitialization operations (those with
ARC references in them).
rdar://problem/35698831
Despite their similar names and uses, these protocols no longer share
much functionality - the former is used to take @objc enums defined in
Swift that conform to Error and expose them as NSErrors, and the
latter handles NS_ERROR_ENUM C enums, which get imported into Swift as
a wrapper around NSError. We can actually simplify them quite a bit.
- Eliminate base protocol __BridgedNSError, which no longer provides
any implementation for _BridgedStoredNSError.
- Eliminate default implementations that match what the compiler would
synthesize.
- Adopt recursive constraints and where-clauses on associated types
(and update the Clang importer to handle this).
- Collapse signed and unsigned default implementations when reasonable.
- Fold _BridgedStoredNSError's _nsErrorDomain into the existing public
requirement CustomNSError.errorDomain.
rdar://problem/35230080
(rather than 'open')
This attribute was originally introduced for Swift classes exposed to
Objective-C, but if it /is/ used on a pure Objective-C class Swift
should respect it. There might be an actual reason, such as a hot code
path in ContrivedExampleKit checking against the class object's
address instead of using -isKindOfClass:.
For source compatibility, only enforce this in Swift 5 mode.
rdar://problem/33971529
Stop creating ImplicitlyUnwrappedOptional<T> so that we can remove it
from the type system.
Enable the code that generates disjunctions for Optional<T> and
rewrites expressions based on the original declared type being 'T!'.
Most of the changes supporting this were previously merged to master,
but some things were difficult to merge to master without actually
removing IUOs from the type system:
- Dynamic member lookup and dynamic subscripting
- Changes to ensure the bridging peephole still works
Past commits have attempted to retain as much fidelity with how we
were printing things as possible. There are some cases where we still
are not printing things the same way:
- In diagnostics we will print '?' rather than '!'
- Some SourceKit and Code Completion output where we print a Type
rather than Decl.
Things like module printing via swift-ide-test attempt to print '!'
any place that we now have Optional types that were declared as IUOs.
There are some diagnostics regressions related to the fact that we can
no longer "look through" IUOs. For the same reason some output and
functionality changes in Code Completion. I have an idea of how we can
restore these, and have opened a bug to investigate doing so.
There are some small source compatibility breaks that result from
this change:
- Results of dynamic lookup that are themselves declared IUO can in
rare circumstances be inferred differently. This shows up in
test/ClangImporter/objc_parse.swift, where we have
var optStr = obj.nsstringProperty
Rather than inferring optStr to be 'String!?', we now infer this to
be 'String??', which is in line with the expectations of SE-0054.
The fact that we were only inferring the outermost IUO to be an
Optional in Swift 4 was a result of the incomplete implementation of
SE-0054 as opposed to a particular design. This should rarely cause
problems since in the common-case of actually using the property rather
than just assigning it to a value with inferred type, we will behave
the same way.
- Overloading functions with inout parameters strictly by a difference
in optionality (i.e. Optional<T> vs. ImplicitlyUnwrappedOptional<T>)
will result in an error rather than the diagnostic that was added
in Swift 4.1.
- Any place where '!' was being used where it wasn't supposed to be
allowed by SE-0054 will now treat the '!' as if it were '?'.
Swift 4.1 generates warnings for these saying that putting '!'
in that location is deprecated. These locations include for example
typealiases or any place where '!' is nested in another type like
`Int!?` or `[Int!]`.
This commit effectively means ImplicitlyUnwrappedOptional<T> is no
longer part of the type system, although I haven't actually removed
all of the code dealing with it yet.
ImplicitlyUnwrappedOptional<T> is is dead, long live implicitly
unwrapped Optional<T>!
Resolves rdar://problem/33272674.
That is, if the wrapped type conforms to special known protocol X via
synthesized conformance to protocol Y which inherits from X, the
wrapper should conform to X as well.
https://bugs.swift.org/browse/SR-6842
...rather than the ad hoc CustomTypeNameManglingAttr I was using
before. As John pointed out, the AST should be semantic wherever
possible.
We may someday want to get out of this being an attribute altogether,
or duplicating information that's available in the original Clang
node, by actually storing a reference to that node somewhere. This is
tricky and mixed up with deciding what hasClangNode() or
getClangDecl() would mean, though, so for now the attribute just
carries the information we need.
(and 'La'...'Lj')
Use this for the synthesized structs for error enums, as described in
the previous commit, instead of reusing the "private discriminator"
feature. I left some space in the APIs for "related entity kinds" that
are longer than a single character, but I don't actually expect to use
it any time soon. It's mostly just easier to deal with StringRef than
with a bare char.
Note that this doesn't perfectly round-trip to the old mangling; I had
it treat these nodes as private discriminators with a prefixed "$"
instead. We don't depend on that for anything, though.
When importing a C enum with the ns_error_domain attribute, we
synthesize a struct containing an NSError object to represent errors
in that domain. That synthesized struct should have a mangled name
that ties it to the original C enum, if we want it to be stable, and
now it does.
Before: $SSC7MyErrorV (a normal struct, which is a lie)
After: $SSC11MyErrorCode13ns_error_enumLLV
kind=Global
kind=Structure
kind=Module, text="__C_Synthesized"
kind=PrivateDeclName
kind=Identifier, text="ns_error_enum"
kind=Identifier, text="MyErrorCode"
Using the "private discriminator" feature allows us to pack in extra
information about the declaration without changing the mangling
grammar, and without stepping on anything the importer is using.
More rdar://problem/24688918
This has three principal advantages:
- It gives some additional type-safety when working
with known accessors.
- It makes it significantly easier to test whether a declaration
is an accessor and encourages the use of a common idiom.
- It saves a small amount of memory in both FuncDecl and its
serialized form.
Swift uses ARC for CF types, so CFRetain and its variants aren't
necessary. But sometimes functions /look/ like retain/release variants
(to the compiler, anyway) but actually do useful things, like
CMBufferQueueDequeueAndRetain. Recognize this with the presence of a
swift_name attribute (either from CF_SWIFT_NAME or from API notes).
rdar://problem/23480844
Update several functions to return a Type/bool pair with the bool
representing whether the type is one that should be implicitly
unwrapped. This bool is surfaced up to the decl importing functions,
allowing them to set the appropriate decl attribute so that the
expression type checker will consider selecting the underlying type of
the optional involved during solving if the expression doesn't type
check with the optional type.
When importing Decls, use the IUO information to set the
ImplicitlyUnwrappedOptionalAttr attribute when appropriate.
We're still generating IUO types at the moment, so this change doesn't
really have much of an affect other than the creation of those
attributes.
This reapplies f1c48daf70 with the test split up so that the
availability bits don't affect other platforms.
Seen as @available attributes being printed with "_" in interface
generation, but fixing it in the importer means they can't leak into
anywhere else.
rdar://problem/30451293
Objective-C subscripts don't have special declarations like
properties; they're just specially-named methods (or method pairs),
and we have to make an independent SubscriptDecl in Swift. This means
that when a subclass wants to make a subscript settable, they just add
the appropriately-named setter method.
Swift handled this by detecting when the getter and setter weren't
declared in the same type, and assuming this meant it was a subclass
adding a setter. Unfortunately, the same condition /also/ picked up
the case where the getter (and only the getter) is /redeclared/ in a
subclass (perhaps to add an attribute), and the new subscript was
getting added to the base class instead of the subclass.
The fix relies on the fact that the original decl we provide is what
we use to look up the other accessor. If the getter and setter are in
different types, whichever one we started with must be the
more-derived one. So the final change is just "did we start with the
setter?" rather than "is there a setter at all?".
I'm not sure why this is only just now causing problems, given that we
seem to have been getting this wrong for years, but it definitely
/was/ wrong and now it's not.
rdar://problem/36033356
(and vice versa)
Inadvertant fallout from 7725e38d96, which concerned accidental ambiguity
when mirroring protocol methods onto an implementing class.
https://bugs.swift.org/browse/SR-5959
Rather than storing contextual types in the type witnesses and associated
conformances of NormalProtocolConformance, store only interface types.
@huonw did most of the work here, and @DougGregor patched things up to
complete the change.
These kinds of synthesized declarations no longer need to go
through the constraint solver, since they have simple enough
bodies that we can construct type checked AST directly:
- rawValue getter and init(rawValue:)
- memberwise struct initializer
- zero struct initializer
Partially reverts f4f8349 (from July!) which caused us to start
importing global blocks with unbridged parameters, breaking source
compatibility. I'm still investigating whether there's an actual hole
in the logic; see next few commits.
rdar://problem/34913634
