Fix an unused variable warning in `Errors.cpp`.
Use brace initialization syntax in `SymbolInfo.cpp` rather than using
a constructor call.
rdar://130992923
This inserts a suitably named function into the stack trace whenever
a dynamic cast failure involves a NULL source or target type.
Very often, crash logs include backtraces with function names but
no log output; with this change, such a backtrace might look like
the following -- note `TARGET_TYPE_NULL` in the function name
here to mark the missing type information:
```
frame #0: __pthread_kill + 8
frame #1: pthread_kill + 288
frame #2: abort + 128
frame #3: swift::fatalErrorv()
frame #4: swift::fatalError()
frame #5: swift_dynamicCastFailure_TARGET_TYPE_NULL()
frame #6: swift::swift_dynamicCastFailure()
frame #7: ::swift_dynamicCast()
```
Resolves rdar://130630157
Prefer `ZeroMemory()` to `::memset()` here.
Use `sizeof(*wszBuffer)` instead of `sizeof(WCHAR)`, just in case.
Don't use `*this=other`, because that motivates tests around `::free()`,
but instead pull the shared code out into some private functions.
Also, fix `SymbolInfo()` to initialize the pointer members.
rdar://130992923
We were calling `SymInitialize()` multiple times, which is wrong, which
was making the `SymbolInfo::lookup()` call fail. Also, we weren't
fetching the module names, so we should do that too.
rdar://130992923
If a type or opaque type descriptor appears inside of a protocol extension of the form:
```
extension P where Self == Nominal { ... }
```
then the runtime representation of the extension context was interpreted by the runtime
demangler as a nominal type extension, even though the parameterization is on the
`<Self>` generic signature of the protocol extension and not the generic signature of
the nominal type. This would cause spurious rejection of mangled names referencing the
extension context because we mistakenly thought that the type arguments mismatched with
the nominal type signature rather than matching them to the extension context.
Add some code to `_findExtendedTypeContextDescriptor` to detect when an extension is
a protocol extension with a `Self == SameType` constraint, and pass the extension along
rather than treating it as a nominal type extension. Fixes rdar://130168101.
Apparently we're missing a cast in `_swift_initRuntimePath()`. Previously
this code was accidentally not being used, which is why we hadn't noticed
it.
rdar://131294724
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.
Track the key argument index separately from the generic parameter index when performing the invertible protocol checking in _checkGenericRequirements. This keeps the indexing correct when a non-key argument is followed by a key argument.
rdar://128774651
The existing lookup uses a hash table with the type's mangled name as the key. Building that key is costly. Add a new table that uses pointer keys, so that we can use the descriptor and arguments directly as the key.
rdar://127621414
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
Emitting a signpost for the first time can trigger lazy setup of the logging system, and doing this in the wrong context can cause deadlocks. Check to see if the logging system is already set up, and only emit signposts if it has been to avoid triggering this.
As it's hard to determine if the "is it set up?" function is available in the SDK we're building against, only do this in OS builds, as it's not particularly useful in local builds.
rdar://124620772
PR #71620 made this behavior conditional as a way to help
provide binary compatibility for legacy software that might
be relying on the old behavior.
So far, it appears the only such problems arose from the
SwiftObject behavior changes, not from SwiftValue behavior.
So let's optimistically back this out and make the new behavior
unconditional.
Resolves rdar://127839540
Use the new `SWIFT_SDK_<sdk>_STATIC_LINKING_SUPPORTED` and
`_STATIC_ONLY` flags instead of hardcoding support for Linux
and WASI.
Also, use the `_LIB_SUBDIR` variable rather than lowercasing
the SDK.
rdar://123504757
rdar://127379960
When the spare bits of an Error objects are used to store tag bits, this caused the enum tag to be lost, which caused the wrong enum cases to be matched.
Merge the three-stage operation originally designed for field vectors into a single unified loop that acts directly on the ivar offsets instead of using a faux field offset vector.
We really don’t need ‘em; we can just adjust the direct field offsets.
The runtime entry point currently uses a weird little hack that we will refactor away shortly.
When an @objc @implementation class requires the use of `ClassMetadataStrategy::Update` because some of its stored properties do not have fixed sizes, we adjust the direct field offsets during class realization by emitting a custom metadata update function which calls a new entry point in the Swift runtime. That entry point adjusts field offsets like `swift_updateClassMetadata2()`, but it only assumes that the class has Objective-C metadata, not Swift metadata.
This commit introduces an alternative mechanism which does the same thing without using any Swift-only metadata. It’s a rough implementation with important limitations:
• We’re currently using the field offset vector, which means that field offsets are being emitted into @objc @implementation classes; these will be removed.
• The new Swift runtime entry point duplicates a lot of `swift_updateClassMetadata2()`’s implementation; it will be refactored into something much smaller and more compact.
• Availability bounds for this feature have not yet been implemented.
Future commits in this PR will correct these issues.
We attempted to use the declaration if it exists, and fall back to dlsym. This didn't actually work and we always call dlsym. Include the right header (when available) and add a weak check to the direct call.
rdar://127116080
* [Runtime] Fix CVW for genreic single payload enums with no extra inhabitants
rdar://126728925
When the payload of a generic SPE did not have any extra inhabitants, we erroneously always treated it as the no payload case.
Additionally the offset and skip values were improperly computed.
* Fixed FileCheck string
The pointer location can be computed from the symbolic reference location and offset, which we already provide, but it's not clear that you should add them together, nor is it clear why this failure would occur. Add the location of the NULL pointer itself to the error message, and also mention that it's probably caused by a missing weak symbol.
