Convert a bunch of places where we're dumping to stderr and calling
`abort` over to using `ABORT` such that the message gets printed to
the pretty stack trace. This ensures it gets picked up by
CrashReporter.
When unconditionally casting from a base to a final derived class, e.g. `base as! Derived`, the program did not abort with a trap.
Instead the resulting null-pointer caused a crash later in the program.
This fix inserts a trap condition for the failing case of such a cast.
rdar://151462303
If you had something like:
struct G<T> {
func f<each U>(_: repeat each U) where T == (repeat each U) {}
}
We would fulfill 'each U' from the metadata for 'G<(repeat each U)>',
by taking apart the tuple metadata for `(repeat each U)` and forming
a pack.
However this code path was only intended to kick in for a tuple
conformance witness thunk. In the general case, this optimization
is not correct, because if 'each U' is substituted with a
one-element pack, the generic argument of `G<(repeat each U)>` is
just that one element's metadata, and not a tuple. In fact, we
cannot distinguish the one-element tuple case, because the wrapped
element may itself be a tuple.
The fix is to just split off FulfillmentMap::searchTupleTypeMetadata()
from searchTypeMetadata(), and only call the former when we're in
the specific situation that requires it.
- Fixes https://github.com/swiftlang/swift/issues/78191.
- Fixes rdar://problem/135325886.
rdar://151176697
While generic types generally have layout strings (when enabled), non-copyable types don't, so
we have to make sure the flag does not get set.
We deallocate an instruction's packs at points where no further
control flow path uses the value. In the case of an alloc_stack,
this will be right after the dealloc_stack. Thus, if alloc_stack
allocates some packs to build type metadata for a tuple type
that contains a pack, and then proceeds to allocate a value
large enough to hold the tuple, we will free the second allocation
first, before we free the pack, as expected.
However, after stack allocating the value, alloc_stack does
some further work to emit debug info. This could result in
emission of additional metadata packs.
Split up the debug info emission into two parts; the first we do
before we perform the stack allocation, the rest we do after.
- Fixes https://github.com/swiftlang/swift/issues/67702.
- Fixes rdar://problem/141363236.
If debug info generation is enabled, set debug location to the
coroutine call instruction to make sure there are no issues with invalid
debug information in LTO.
This happens because in LTO, if a call to a function doesn't contain a
debug location, we see the warning:
inlinable function call in a function with debug info must have a
!dbg location
ld: warning: Invalid debug info found, debug info will be stripped
Which then strips the debug info from the entire .o file linked into the
dylib.
It derives the address of the first element of a vector, i.e. a `Builtin.FixedArray`, from the address of the vector itself.
Addresses of other vector elements can then be derived with `index_addr`.
rdar://149985633
Using at least Int8 here allows LLVM to apply more optimizations, reducing code size, avoiding stack allocations and as a result often eliminating complete stack frames.
When Swift visits an `ExtensionDecl` from an `@objc @implementation`
extension, it fetches the implemented Objective-C interface declaration
from the header file and adds to the visitor.
We don't want these API records from `APIGenRecorder` for Swift API
descriptor, because we cannot correctly reason about their API access as
they depend on the header group which Swift doesn't know about.
Resolves rdar://148943382
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
Issue introduced by 0d2d6cb8a0.
`llvm::getPointerAuthStableSipHash` produces the combined result of
the obsoleted `clang::CodeGen::computeStableStringHash` and
our `getDiscriminatorForHash`, so we no longer need to call both.
This change emits debug info for witness tables passed into generic
functions when a generic type is constrained to a protocol. This
information is required for LLDB's generic expression evaluator
to work in such functions.
rdar://104446865
This changes the isIsolatingCurrentContext function to return `Bool?`
and removes all the witness table trickery we did previously to detect
if it was implemented or not. This comes at a cost of trying to invoke
it always, before `checkIsolated`, but it makes for an simpler
implementation and more checkable even by third party Swift code which
may want to ask this question.
Along with the `withSerialExecutor` function, this now enables us to
check the isolation at runtime when we have an `any Actor` e.g. from
`#isolation`.
Updates SE-0471 according to
https://forums.swift.org/t/se-0471-improved-custom-serialexecutor-isolation-checking-for-concurrency-runtime/78834/
review discussions
Swift does not support storing fields in the padding of the previous
fields just yet, so let's not import fields like that from C++.
Represent them as opaque blobs instead.
Fixes#80764
rdar://149072458
