We don't want the machine calling conventions for closure invocation functions to necessarily be tied to the convention for normal thin functions or methods. NFC yet; for now, 'closure' follows the same behavior as the 'method' convention, but as part of partial_apply simplification it will be a requirement that partial_apply takes a @convention(closure) function and a box and produces a @convention(thick) function from them.
Allow it only to have one context parameter, whose ownership convention matches the convention of the resulting thick function, effectively limiting it to binding a closure invocation function to its context.
When we call the DeclContext variants of these, use the
DeclContext's GenericEnvironment instead of GenericParamList.
Also, these functions would take a resolver argument, but we
always passed in nullptr, so just remove it now.
The old GenericParamList-based versions are still there
since they're called directly from SIL. They will go away
once SILFunction::ContextGenericParams is replaced with
a GenericEnvironment.
Like NSObject, CFType has primitive operations CFEqual and CFHash,
so Swift should allow those types to show up in Hashable positions
(like dictionaries). The most general way to do this was to
introduce a new protocol, _CFObject, and then have the importer
automatically make all CF types conform to it.
This did require one additional change: the == implementation that
calls through to CFEqual is in a new CoreFoundation overlay, but the
conformance is in the underlying Clang module. Therefore, operator
lookup for conformances has been changed to look in the overlay for
an imported declaration (if there is one).
https://bugs.swift.org/browse/SR-2388
for weak semantics, that is!
94a9c512b9 made some changes to loading
weak references by adding some information in the lower bits with
respect to locking. These bits need to be masked out when performing a
load, such as when we want to get the metadata pointer for a class
instance. This normally works fine when going through the normal weak
loading functions in the runtime.
When the runtime function swift_ClassMirror_subscript gets the offset of
one of its stored properties, it immediately packages it into the the
ad-hoc existential container, known as just `Mirror` in the runtime.
However, the weak reference isn't aligned! It has bit 1 set. We weren't
loading the weak reference here as we would during normal SILGen, such
as with a weak_load instruction. Simulate that here and make the
reference strong before putting it into the Mirror container, which also
clears those lower bits.
rdar://problem/27475034
There are still a couple of other cases to handle, namely the
unowned(safe) and unowned(unsafe) reference kinds. There may be other
places where an unaligned pointer is problematic in the runtime, which
we should audit for correctness.
rdar://problem/27809991
I apologize in advance to @jrose-apple, who is not a fan
of this fix ;-)
In unoptimized builds, the convenience initializers on
DispatchQueue allocate and immediately deallocate an
instance of OS_dispatch_queue prior to calling the
C function that returns the "real" instance.
This is because we don't have a way to write user-defined
factory initializers yet; convenience initializers still
have an 'initializing' entry point that takes an existing
instance, which we have no choice but to throw away.
Unfortunately, when we perform the fake allocation, we
look up class metadata by calling the wrong Swift runtime
function, causing a crash when we send +allocWithZone:.
Fix this so that the metadata is accessed via a lookup
from the Objective-C runtime, instead of making a totally
fake 'foreign metadata' object -- it looks like there was
code for this already, it just wasn't used in all cases.
While getting metadata for a runtime-only class should be
rare, this feels like a real bug fix, to me.
Second, we would ultimately free the fake object by sending
-release, however OS_dispatch_queue has an override of
-dealloc which doesn't like to be called with a completely
uninitialized instance.
Here, I'm going to drop all pretense of sanity. The patch
just changes IRGen to lower the dealloc_partial_ref instruction
as a call to the object_dispose() Objective-C runtime function
when the class in question is a runtime-only class. This
frees the object without running -dealloc, which *happens*
to work for OS_dispatch_queue.
Fixes <rdar://problem/27226313>.
This reverts commit dc24c2bd34.
Turns out Chris fixed the build but when I was looking at the bots, his fix had
not been tested yet, so I thought the tree was still red and was trying to
revert to green.
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.
A given Objective-C error enum, which is effectively an NS_ENUM that
specifies its corresponding error domain, will now be mapped to an
ErrorProtocol-conforming struct that wraps an NSError, much like
NSCocoaError does. The actual enum is mapped to a nested "Code"
enum. For example, CoreLocation's CLError becomes:
struct CLError : ErrorProtocol {
let _nsError: NSError
// ...
@objc enum Code : Int {
case ...
}
}
This implements bullet (2) in the proposed solution of SE-0112, so
that Cocoa error types are mapped into structures that maintain the
underlying NSError to allow more information to be extracted from it.
Add initial support for modelling DLL Storage semantics for global values. This
is needed to support the indirect addressing mechanism used on Windows.
I noticed even with multi-payload enum layout working, remote
reflection could not understand Set and Dictionary, because of
issues with Objective-C protocols in the standard library that
are used in the representation of those types.
The problem is that we were taking a different code path and
not emitting a field descriptor. A field descriptor is necessary
to differentiate Objective-C, class-bound and opaque protocols
from each other, so that existentials can use the correct
representation.
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.
It is not valid LLVM IR to have a function call without a location to an
inlinable function inside a function with debug info — this makes it impossible
to construct inline information.
This patch adds an assertion and fixes up several places across IRGen where
such a situation could happen.
rdar://problem/26955467
For now, just run the existing SILGen test to completion. I'll work on
more tests later, I wanted to check this stuff in before it bitrots
any further.
Mark the explicit section for the nominal type metadata being emitted. This is
constant data (post-relocation). Map this to __TEXT,__const on MachO, .rodata
on ELF and .rdata on COFF. Add the cases for COFF and ELF, and change the
switch to be covered.
Instead of hooking into nominal type and extension emission
and walking all conformances of those declarations, let's
just directly hook into the logic for emitting conformances.
This fixes an issue where we would apparently emit duplicate
conformances, as well as unnecessary conformances that are
defined elsewhere.
Hide the writes in the instrumentation when building for TSan to avoid false positives.
This patch relies on the following commit into the compiler-rt repo:
r269855: [tsan] Ensure mmap respects ignore_interceptors_accesses
Mark the explicit section for the nominal type metadata being emitted. This is
constant data (post-relocation). Map this to __TEXT,__const on MachO, .rodata
on ELF and .rdata on COFF. Add the cases for COFF and ELF, and change the
switch to be covered.
This protocol lets us identify swift_newtype'd types. More
importantly, use protocol extensions to make it easy to transfer
specific conformances from the underlying type to the wrapper
type. So, for example, if the underlying type is Hashable, make the
wrapper type Hashable as well. Do the same for Equatable, Comparable,
and _ObjectiveCBridgeable. Fixes rdar://problem/26010804.
Rather than collection nominal type and extension decls and emit
reflection metadata records in one go, we can emit them as they
are encountered and instead collection builtin types referenced
by those at the end.
For now, just enough for lowering.
Perhaps we should have a way to always just get this information
from metadata instead, since protocol metadata is always static
and not instantiated.
This would require the static "object file" interface used by
swift-reflection-dump to take a callback for symbol lookup.
