without relying on spare bit information in the reflection metadata
(which was added in #40906). As a result, we can remove the
code from #40906.
This is the first step in such removal. It removes the RemoteMirror
code for looking up such metadata. It leaves behind:
* Sufficient stubs for LLDB to continue to build. Once LLDB is updated, these stubs can be removed as well.
* The compiler code to emit such metadata. This allows new binaries to still reflect MPEs on older runtimes. This will need to be kept for a transitional period.
This replaces a number of `#include`-s like this:
```
#include "../../../stdlib/public/SwiftShims/Visibility.h"
```
with this:
```
#include "swift/shims/Visibility.h"
```
This is needed to allow SwiftCompilerSources to use C++ headers which include SwiftShims headers. Currently trying to do that results in errors:
```
swift/swift/include/swift/Demangling/../../../stdlib/public/SwiftShims/module.modulemap:1:8: error: redefinition of module 'SwiftShims'
module SwiftShims {
^
Builds.noindex/swift/swift/bootstrapping0/lib/swift/shims/module.modulemap:1:8: note: previously defined here
module SwiftShims {
^
```
This happens because the headers in both the source dir and the build dir refer to SwiftShims headers by relative path, and both the source root and the build root contain SwiftShims headers (which are equivalent, but since they are located in different dirs, Clang treats them as different modules).
Apply a blanket pass of including `new` for the placement new allocation
and namespacing the call to the global placement new allocator. This
should repair the Android ARMv7 builds.
This adds a new reflection record type carrying spare bit information for multi-payload enums.
The compiler includes this for any type that might need it in order to accurately reflect the contents of the enum. The RemoteMirror library will use this if present to determine how to project the contents of the enum. If not present (for example, in older binaries), the RemoteMirror library falls back on an internal calculation of the spare bitmask.
A few notes:
* The internal calculation is not perfect. In particular, it does not support MPEs that contain other enums (e.g., optionals). It should accurately refuse to project any MPE that it does not correctly support.
* The new reflection field is designed to be expandable; this might someday avoid the need for a new section.
Resolves rdar://61158214
The sections to which the start/stop symbols are being applied do not
guarantee pointer alignment. In particular, the field metadata is
aligned to a 4-byte boundary, which is less then the pointer alignment
of `uintptr_t`. This results in extra padding in the data which is
going to cause the iteration to run off the end. A similar byte
alignment is forced for the markers in the ELF case as well. This fixes
one of the reflection tests on Windows where we were attempting to
decode the padding as an entry.
The default attribute on the section is read/write. This would cause
the section to have different attributes when compiled. The linker
would then preserve the section rather than merge it into the right
location. This was noticed when linking with `link.exe`.
The Windows constructor was not populated properly, with the protocol
list being dropped. Ensure that all the fields are initialised
properly. Thanks to clang's `-Wmissing-field-initializers` warning to
help catch this.
On windows, we create synthetic markers with grouping identifiers to
ensure that the markers are sorted properly and merged. We would
previously mark the section as read/write rather than read-only causing
warnings when linking. Correct the attributes. This ensures the proper
linking of the modules.
Restructure the COFF metadata handling to use the linker section
grouping to emit section start/stop markers in the appropriate location.
This allows us to lookup the sections statically without having to the
walk the entire image structure.
Introduce a constructor for PE/COFF binaries. This will ensure that the
registration occurs for all modules appropriately. This should resolve
rdar://problem/19045112. The registration should occur prior to
`DllMain` being invoked from `DllMainCRTStartup`.
