It's hard to tell why a crash occurred with just "Could not allocate memory." Modify the message to include the size/alignment, which will help distinguish between an actual lack of memory and a request for an excessively large allocation.
While we're in there, add \n to a bunch of other fatal error helper functions that didn't have it.
This introduces a non-Darwin (non-CrashReporter) storage for error
messages to allow extraction for crash reporting. This is initially
meant to be used on Windows, though it is generic enough to be used on
any platform.
This also adds a function to demangle a symbol, and a way for the
backtracing code to report warning messages to the same place as
the main runtime.
I'd like to rename the _swift_isThunkFunction() SPI also, but we
can't do that until we've made the changes to the _Backtracing
library, so we'll do that there instead.
rdar://110261430
The demangling library can't use the error handling from the main runtime
because it isn't always linked with it. However, it's useful to have
some error handling, and in particular to be able to get data into the
crash logs.
This is complicated because of the way the demangling library gets used,
the upshot of which is that I've had to add a second object library just
for libswiftCore's use, so that the demangler will use the runtime's
error handling functions when present, and fall back on its own when
they aren't.
rdar://89139049
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
Describe the consequences of missing metadata instead of just posting a scary
message about a bug. Furthermore, since these warnings tend to show up in
playgrounds, and probably aren't relevant to the user of a playground, suppress
them when running in a playground. rdar://problem/44642942
We want to be able to potentially introduce new metadata kinds in future Swift compilers, so a runtime ought to be able to degrade gracefully in the face of metadata kinds it doesn't know about. Remove attempts to exhaustively switch over metadata kinds and instead treat unknown metadata kinds as opaque.
* Check for overflow in incrementWeak().
This mirrors what is currently done for unowned reference counts, where overflowing the side table field produces a fatal error. Without this, the count silently wrapped from 2^31-1 to 0, which then caused breakage when the balancing releases happened (possibly including use-after-free bugs).
* Fix the implementation of RefCounts::getWeakCount().
The previous implementation was only appropriate for heap objects, but not side tables. This resulted in the weak count always returning 0 or 1. This change specializes the implementation for the two different cases and returns the correct count for side tables.
* Test large weak retain counts.
This tests the largest allowed weak retain count, as well as the overflow check when that count is exceeded.
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
On 32bit platforms there are 7 bits reserved for the unowned retain count. This
makes overflow a likely scenario. Implement overflow into the side table.
rdar://33495003
* Extend Swift runtime issue reporting for @objc inference to include details about the declaration of the method (that is missing the @objc annotation) and a suggested fix-it. This changes the ABI of RuntimeErrorDetails, so we're also bumping the version.
* Update SwiftObject.mm
* Implements a debugger hook (breakpoint) API and data structure. This structure is passed to the debugger and describes extra information about a fatal error or a non-fatal warning, which should be logged as a runtime issue.
This debugger hook is then used from two places, which currently only log to stderr:
- Runtime exclusivity violations.
- Swift 3 implicit Obj-C entrypoints.
A subsequent LLDB support will be able to catch these callbacks and show the runtime issues in a better way than just logging them to stderr. When the debugger is not attached, this shouldn't have any effect.
- Add RuntimeTarget template This will allow for converting between
metadata structures for native host and remote target architectures.
- Create InProcess and External templates for stored pointers
Add a few more types to abstract pointer access in the runtime
structures but keep native in-process pointer access the same as that
with a plain old pointer type.
There is now a notion of a "stored pointer", which is just the raw value
of the pointer, and the actual pointer type, which is used for loads.
Decoupling these allows us to fork the behavior when looking at metadata
in an external process, but keep things the same for the in-process
case.
There are two basic "runtime targets" that you can use to work with
metadata:
InProcess: Defines the pointer to be trivially a T* and stored as a
uintptr_t. A Metadata * is exactly as it was before, but defined via
AbstractMetadata<InProcess>.
External: A template that requires a target to specify its pointer size.
ExternalPointer: An opaque pointer in another address space that can't
(and shouldn't) be indirected with operator* or operator->. The memory
reader will fetch the data explicitly.
...and explicitly mark symbols we export, either for use by executables or for runtime-stdlib interaction. Until the stdlib supports resilience we have to allow programs to link to these SPI symbols.
Many of the report* entry points are specific to the stdlib assert implementation, so belong in the stdlib. Keep a single `reportError` entry point in the runtime to handle the CrashReporter/ASL interface, and call down to it from the assert implementation functions.
Set up a separate libSwiftStubs.a archive for C++ stub functionality that's needed by the standard library but not part of the core runtime interface. Seed it with the Stubs.cpp and LibcShims.cpp files, which consist only of stubs, though a few stubs are still strewn across the runtime code base.
