* Change the RemoteMirror API to have extensible data layout callback
* Use DLQ_Get prefix on DataLayoutQueryType enum values
* Simplify MemoryReaderImpl and synthesize minimalDataLayoutQueryFunction
Mark the public interfaces with the appropriate visibility/dll storage.
This fixes an issue with the Windows build which keeps the
SwiftRemoteMirror.dll out of date constantly as no import library is
created. That occurs due to the fact that the library does not export
any interfaces.
Take the opportunity to move the public interfaces to protected
visibility on ELF.
* Remove getPointerSize and getSizeSize functions, replace with a single PointerSize value.
* Remove imageLength parameter from addImage, calculate it internally instead.
* Check remote mirrors libraries' metadata version and reject them if it's too old.
* Shim GetStringLength and GetSymbolAddress for the legacy library since we don't pass the caller's context pointer through directly.
* Actually set the IsLegacy flag in the Library struct.
* Implement ownsObject by tracking each added image's data segment and checking metadata pointers against them. The previous approach didn't work.
This makes resolving mangled names to nominal types in the same module more efficient, and for eventual secrecy improvements, also allows types in the same module to be referenced from mangled typerefs without encoding any source-level name information about them.
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.
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`.
These changes caused a number of issues:
1. No debug info is emitted when a release-debug info compiler is built.
2. OS X deployment target specification is broken.
3. Swift options were broken without any attempt any recreating that
functionality. The specific option in question is --force-optimized-typechecker.
Such refactorings should be done in a fashion that does not break existing
users and use cases.
This reverts commit e6ce2ff388.
This reverts commit e8645f3750.
This reverts commit 89b038ea7e.
This reverts commit 497cac64d9.
This reverts commit 953ad094da.
This reverts commit e096d1c033.
rdar://30549345
This patch splits add_swift_library into two functions one which handles
the simple case of adding a library that is part of the compiler being
built and the second handling the more complicated case of "target"
libraries, which may need to build for one or more targets.
The new add_swift_library is built using llvm_add_library, which re-uses
LLVM's CMake modules. In adapting to use LLVM's modules some of
add_swift_library's named parameters have been removed and
LINK_LIBRARIES has changed to LINK_LIBS, and LLVM_LINK_COMPONENTS
changed to LINK_COMPONENTS.
This patch also cleans up libswiftBasic's handling of UUID library and
headers, and how it interfaces with gyb sources.
add_swift_library also no longer has the FILE_DEPENDS parameter, which
doesn't matter because llvm_add_library's DEPENDS parameter has the same
behavior.
The approach here is to split this into two cases:
- If all case payloads have a fixed size, spare bits may be
potentially used to differentiate between cases, and the
remote reflection library does not have enough information to
compute the layout itself.
However, the total size must be fixed, so IRGen just emits a
builtin type descriptor (which I need to rename to 'fixed type
descriptor' since these are also used for imported value types,
and now, certain enums).
- If at least one case has a size that depends on a generic
parameter or is a resilient type, IRGen does not know the size,
but this means fancy tricks with spare bits cannot be used either.
The remote reflection library uses the same approach as the
runtime, basically taking the maximum of the payload size and
alignment, and adding a tag byte.
As with single-payload enums, we produce a new kind of
RecordTypeInfo, this time with a field for every enum case.
All cases start at offset zero (but of course this might change,
if for example we put the enum tag before the address point).
Also, just as with single-payload enums, there is no remote
'project case index' operation on ReflectionContext yet.
So the the main benefit from this change is that we don't entirely
give up when doing layout of class instances containing enums;
however, tools still cannot look inside the enum values themselves,
except in the simplest cases involving optionals.
Notably, the remote reflection library finally understands all
of the standard library's collection types -- Array, Character,
Dictionary, Set, and String.
Attempt to lay out single-payload enums, using knowledge of extra
inhabitants where possible.
- The extra inhabitants of an aggregate are the extra inhabitants of
the first field. If the first field is empty, there are no extra
inhabitants, and subsequent fields do not affect anything.
- Function pointers and metatypes have different extra inhabitants
than Builtin.RawPointer, so have IRGen emit distinct builtin type
descriptors for those.
- Opaque existentials do not have extra inhabitants.
- Weak references do not have extra inhabitants.
Also, fix IRGen to emit more accurate enum reflection metadata in
these two cases:
- We now record whether enum cases are indirect or not. An indirect
case is the same as a payload case with Builtin.NativeObject.
- We now record whether a case is empty or not using the same logic
as the rest of IRGen. Previously, we would incorrectly emit a
payload type for a case with a payload that is an empty struct,
for example.
At this point we don't have a way to get the currently inhabited
enum case from a value. However, this is still an improvement because
we can still reflect other fields of aggregates containing enums,
instead of just giving up.
Finally make some methods on TypeCoverter private, and use 'friend'
to allow them to be accessed from other internal classes, making the
public API simpler.
We want to be able to build a target with just the platform-specific
libswiftRemoteMirror library. This should be a change in build logic
for existing presets but allows for a separate preset to be defined
that just builds the library if/when it's necessary.
- Add --build-swift-remote-mirror option to build-script-impl
- Add swift-remote-mirror known install component.
- Only add SwiftRemoteMirror targets if SWIFT_BUILD_REMOTE_MIRROR is on.
- Move libswiftRemoteMirror into the swift-remote-mirror install component.
- Add swift-remote-mirror install components to existing presets.
rdar://problem/27085666
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
As a first step to allowing the build script to build *only*
static library versions of the stdlib, change `add_swift_library`
such that callers must pass in `SHARED`, `STATIC`, or `OBJECT_LIBRARY`.
Ideally, only these flags would be used to determine whether to
build shared, static, or object libraries, but that is not currently
the case -- `add_swift_library` also checks whether the library
`IS_STDLIB` before performing certain additional actions. This will be
cleaned up in a future commit.
Although this is a target library, it does not need to link against
the standard library, because it doesn't have any Swift content in
it. We need to add a separate build flag for having CMake content
because saying a library "IS_STDLIB" isn't correct for this case.
rdar://problem/26399625
They would think the type 'addr_t' is defined in the standard library
because it has the same name format with the types in <cstdint>. In
addition, the definition conflicts in Cygwin which defines it differently
in the system library.
