Switch StringObject and StringGuts from opaquely storing tagged cocoa
strings into storing small strings. Plumb small string support
throughout the standard library's routines.
This includes global generic and non-generic global access
functions, protocol associated type access functions,
swift_getGenericMetadata, and generic type completion functions.
The main part of this change is that the functions now need to take
a MetadataRequest and return a MetadataResponse, which is capable
of expressing that the request can fail. The state of the returned
metadata is reported as an second, independent return value; this
allows the caller to easily check the possibility of failure without
having to mask it out from the returned metadata pointer, as well
as allowing it to be easily ignored.
Also, change metadata access functions to use swiftcc to ensure that
this return value is indeed returned in two separate registers.
Also, change protocol associated conformance access functions to use
swiftcc. This isn't really related, but for some reason it snuck in.
Since it's clearly the right thing to do, and since I really didn't
want to retroactively tease that back out from all the rest of the
test changes, I've left it in.
Also, change generic metadata access functions to either pass all
the generic arguments directly or pass them all indirectly. I don't
know how we ended up with the hybrid approach. I needed to change all
the code-generation and calls here anyway in order to pass the request
parameter, and I figured I might as well change the ABI to something
sensible.
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
The runtime hash table for protocol conformances is keyed by (type, protocol),
where the type can be either a type metadata pointer or a type context
descriptor. The latter is preferred for generic and resilient types, because
a single entry in the cache can work for any instantiation.
However, not all type metadata has a corresponding type context descriptor.
For example, a class that is dynamically subclassed by the Objective-C
runtime won't have a type context descriptor. In such cases, our key
into the hash table was (NULL, protocol) leading to mistaken
conformances for different dynamically-subclassed types.
Introduce a NULL check for the type of the hash table key, which
illustrates the problem in a number of existing tests that exercise
the runtime, and teach the runtime to use the type context descriptor
as the key only when it's non-NULL, falling back to the type metadata
pointer otherwise.
Fixes rdar://problem/38053213.
This converts the instances of the pattern for which we have a proper
substitution in lit. This will make it easier to replace it
appropriately with Windows equivalents.
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.
This new format more efficiently represents existing information, while
more accurately encoding important information about nested generic
contexts with same-type and layout constraints that need to be evaluated
at runtime. It's also designed with an eye to forward- and
backward-compatible expansion for ABI stability with future Swift
versions.
Include the initial implementation of _StringGuts, a 2-word
replacement for _LegacyStringCore. 64-bit Darwin supported, 32-bit and
Linux support in subsequent commits.
Following up on the fixes for rdar://problem/35330067. If a class inherits a class from another module with missing fields, we need to treat its size and alignment as opaque, just like the base class itself. We also need to lay out such class at runtime, since we don't know the size, alignment, or field offsets at compile time; relying on the ObjC runtime alone will slide the ivar offsets, but not the Swift instance size and alignment. Fixes rdar://problem/35747485.
We would miscompile in mixed-language-version projects when a Swift class was compiled for one language version, while using Objective-C-imported types that are only available to that version, and then imported into a Swift module with a different language version that wasn't able to see all of the properties because of incompatible imported types. This manifested in a number of ways:
- We assumed we could re-derive the constant field offsets of the class's ivars from the layout, which is wrong if properties are missing, causing accesses to final properties or subclass properties to go to the wrong offsets.
- We assumed we could re-derive the instance size and alignment of a class instance in total, causing code to allocate the wrong amount of memory.
- We neglected to account for the space that stored properties take up in the field offset vector of the class object, causing us to load vtable entries for following subclass methods from the wrong offsets.
Eventually, resilience should reduce our exposure to these kinds of problems. As an incremental step in the right direction, when we look at a class from another module in IRGen, treat it as always variably-sized, so we don't try to hardcode offsets, size, or alignment of its instances. When we import a class, and we're unable to import a stored property, leave behind a new kind of MissingMemberDecl that records the number of field offset vector slots it will take up, so that we lay out subclass objects and compute vtable offsets correctly. Fixes rdar://problem/35330067.
A side effect of this is that the RemoteAST library is no longer able to provide fixed field offsets for class ivars. This doesn't appear to impact the lldb test suite, and they will ultimately need to use more abstract access patterns to get ivar offsets from resilient classes (if they aren't already), so I just removed the RemoteAST test cases that tested for class field offsets for now.
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
Use the modern spelling for the nullability attributes in the test mock
headers. Currently, this was relying on the predefined macros from
clang to work. However, those are only available on Darwin targets.
This is needed to make the mock environments more portable.
Logs a warning the first time a problematic class is archived or
unarchived. We expect people to actually fix these issues, so the
performance of the warning isn't too important.
Sample output:
[timestamp] Attempting to archive Swift class '_Test.Outer.ArchivedThenUnarchived', which does not have a stable runtime name.
[timestamp] Use the 'objc' attribute to ensure that the runtime name will not change: "@objc(_TtCC5_Test5Outer22ArchivedThenUnarchived)"
[timestamp] If there are no existing archives containing this class, you can choose a unique, prefixed name instead: "@objc(ABCArchivedThenUnarchived)"
Finishes rdar://problem/32414508
This function checks if a mangled class name is going to be written into an NSArchive.
If yes, a warning should be printed and the return value should indicate that.
TODO: print the actual warning
rdar://problem/32414508
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
Only emit calls to Builtin.swift3ImplicitObjCEntrypoint() when we are
in Swift 4 mode with `-enable-swift3-objc-inference`, which is a
transitional state in which one is debugging the use of the
deprecated @objc entrypoints. Fixes rdar://problem/32122408.
