Add a new scatterBits function that is simpler and more generic
than the old interleaveSpareBits function. It is essentially a
constant version of the emitScatterBits function.
SR-10590 | rdar://problem/50968433 appears to be caused by an LLVM JIT bug where GOT-equivalent
globals get emitted with incorrect alignment. Not marking the GOT equivalent as unnamed_addr
(which prevents it from getting folded into the GOT, or other equivalent constants) appears
to work around the issue.
Asking for the layout of the interface type apparently gives the wrong answer,
causing key paths to access stored properties of generic classes using the wrong
strategy.
Fixes SR-10167 | rdar://problem/49230751.
The change replaces 'set bit enumeration' with arithmetic
and bitwise operations. For example, the formula
'(((x & -x) + x) & x) ^ x' can be used to find the rightmost
contiguous bit mask. This is essentially the operation that
SetBitEnumerator.findNext() performed.
Removing this functionality reduces the complexity of the
ClusteredBitVector (a.k.a. SpareBitVector) implementation and,
more importantly, API which will make it easier to modify
the implementation of spare bit masks going forward. My end
goal being to make spare bit operations work more reliably on
big endian systems.
Side note:
This change modifies the emit gather/scatter functions so that
they work with an APInt, rather than a SpareBitVector, which
makes these functions a bit more generic. These functions emit
instructions that are essentially equivalent to the parallel bit
extract/deposit (PEXT and PDEP) instructions in BMI2 on x86_64
(although we don't emit those directly currently). They also map
well to bitwise manipulation instructions on other platforms (e.g.
RISBG on IBM Z). So we might find uses for them outside spare bit
manipulation in the future.
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
An @objc convenience initializer can replace 'self'. Since IRGen
has no way to tell what the new 'self' value is from looking at
SIL, it always refers back to the original 'self' argument when
recovering DynamicSelfType metadata. This could cause a crash
if the metadata was used after the 'self' value had been
replaced.
To fix the crash, always insert the metadata recovery into the
entry block, where the 'self' value should be valid (even if
uninitialized, the 'isa' pointer should be correct).
Fixes <rdar://problem/50594689>.
This logic is no longer guarded by a flag. Sema will still emit certain
diagnostics if the flag is not specified though.
Progress on <rdar://problem/49090631>.
At some point it might be useful to be able to use an appropriate
explosion schema to explode payloads but currently the code that
handles this is unused. There are lots of different ways we might
add this functionality in the future and it isn't clear that the
existing code will be the best way to use explosion schemas in the
future.
For now remove this dead code so that its presence doesn't obscure
the code that is actually in use.
- In Sema, don't traverse nested declarations while deducing the opaque return type. This would
cause returns inside nested functions to clobber the return type of the outer function.
- In IRGen, walk the list of opaque return types we keep in the SourceFile already for type
reconstruction, instead of trying to visit them ad-hoc as part of walking the AST, since
IRGen doesn't normally walk the bodies of function decls directly.
Fixes rdar://problem/50459091
They aren't normally decl contexts, but if one has an opaque type, we want to be able to record
the property as a context so that we can reconstruct it in RemoteAST.
If -enable-anonymous-context-mangled-names is enabled, meaning that we assign names to
anonymous context descriptors for discovery by RemoteAST, then include opaque type descriptors
in the type metadata record table so that they can also be found at runtime by RemoteAST for
debugger support.
This allows the conversion of the Windows `BOOL` type to be converted to
`Bool` implicitly. The implicit bridging allows for a more ergonomic
use of the native Windows APIs in Swift.
Due to the ambiguity between the Objective C `BOOL` and the Windows
`BOOL`, we must manually map the `BOOL` type to the appropriate type.
This required lifting the mapping entry for `ObjCBool` from the mapped
types XMACRO definition into the inline definition in the importer.
Take the opportunity to simplify the mapping code.
Adjust the standard library usage of the `BOOL` type which is now
eclipsed by the new `WindowsBool` type, preferring to use `Bool`
whenever possible.
Thanks to Jordan Rose for the suggestion to do this and a couple of
hints along the way.
When Swift always copied the overlay dylibs into app bundles, it was OK
for these symbol references to be non-weak, but with the overlays now
part of the OS on Apple platforms, we need to handle backward deployment
scenarios where a new overlay does not exist on an old OS version.
A weak reference will serve to pull in the overlay dylib if it exists,
without causing a fatal error if it does not. rdar://problem/50110036
A workaround in codeview debuginfo generation was to declare a condfail
instruction as inlined to avoid using 0 as an artificial line location.
However, this was done without accounting for scopes that were already
legitimately inlined. So we'd end up with a condfail inlined from
function B into function A and then the IRGen for the condfail was
being given a debugloc claiming to have been inlined again. This was
causing a sitaution where we'd have debug info forfunctionA owning an
instruction which claimed it was owned by a different function.
Fix this by first checking if the `LastScope` was already inlined and,
if so, just used that scope instead.
