After https://github.com/swiftlang/swift/pull/85655, DI types for
existential typealiases and their inner protocol types are created,
which may encounter conflicts in the DIRefMap cache and assert failures
because they can have identical mangled names. This change fixes this
issue by using a separate cache for existential typealiases to avoid
such conflicts.
Issue https://github.com/swiftlang/swift/issues/86313
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
When using compilation caching, make sure the debug info emitted in the
swift TU references PCM files via CASID instead of file path. This
allows dsymutil and lldb to load clang modules correctly from CAS,
instead of relying on file system to load the file.
rdar://167054494
We had introduced coroframe_entry downstream while the upstream proposal
was discussed. It has since been merged upstream, so this commit changes
the code to use the upstream intrisic, avoiding a binary incompatibility
in the IR w.r.t. upstream.
Previously debug info made not difference between an existential type and a
protocol type. This caused us to loose typealiases such as
typealias Alias = ProtocolType
in the debug info.
rdar://161134092
We currently disallow these by deleting them in the `swift` namespace.
This approach has several loopholes, all of which ultimately work
because we happen to define specializations of `simplify_type` for
`swift::Type`:
* `llvm::isa/cast/dyn_cast`. The deleted partial specializations will
not be selected because they are not defined in the `llvm` namespace.
* The argument is a non-const `Type`. The deleted function templates
will not be selected because they all accept a `const Type &`, and
there is a better `Y &Val` partial specialization in LLVM.
* Other casting function templates such as `isa_and_nonull` and
`cast_if_present` are not deleted.
Eliminate these loopholes by instead triggering a static assertion
failure with a helpful message upon instantiation of `CastInfo` for
`swift::Type`.
This new option allows the Driver to pass the path to a compilation
job's own binary swiftmodule artifact to the frontend. The compiler
then stores this path in the debug info, to allow clients like LLDB to
unambiguously know which binary Swift module belongs to which compile
unit.
rdar://163302154
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
For swift async debug info, we create llvm.dbg.declare that contain
locations which may not be a pointer or int. This is fine, because the
CoroSplitter pass fixes up those llvm.dbg.declares later.
However, with a recent change to the LLVM Verifier, there is a check
that asserts if there is a llvm.dbg.declare with a location other than
a pointer or an int.
To workaround the problem, we created a new llvm.dbg.coroframe_entry
intrinsic that doesn't have the same restriction as llvm.dbg.declare.
This patch ensures that in async code, we now emit the new
llvm.dbg.coroframe_entry intrinsic, instead of llvm.dbg.declare
intrinsic
rdar://157299589
rdar://157509307
The stable/21.x branch is not happy with us setting the object pointer
flag here because it now asserts that this flag is set for at most one
function parameter. We should add a dedicated routine for instance
method parameters. For now, stop setting the flag altogether to unblock
the stdlib build on rebranch.
inside function returning it
A stack overflow would happen when the compiler tried emitting debug
info for a function whose opaque return type was declared inside the
function itself. This fixes the issue by emitting a forward declaration
for the function before emitting it.
rdar://150313956
When creating a skeleton Compile Unit, the DIFile passed
in, it always uses the include path. This leads to the DW_AT_comp_dir
being wrong, if the -file-compilation-dir option is passed, we need to
use the remapped compilation dir passed in to the DIFile instead.
This patch fixes that problem.
Fix my mistake in 66a6df9a44. `false` is
the wrong value for the new `Implicit` parameter because it causes the
`FlagArtificial` flag to not be set as before that change. The flag
itself looks appropriate because the entry is constructed for a built-in
type.
