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.
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.
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
When generating debug symbols for private Clang types (which we started
importing recently), the compiler crashes due to an assertion failure
from ClangModuleUnit::getDiscriminatorForPrivateDecl(), which is called
by getFilePrivateScope().
This patch fixes the issue crash by not calling getFilePrivateScope()
for Clang types. A discriminator is usually needed to disambiguate
private Swift types declared in different files, but Clang types follow
different scoping conventions that make this discriminator unnecessary.
rdar://148481025
The module name changes the symbol mangling, and also causes
TBDGen to emit linker directives. To separate out these two
behaviors, introduce a terrible hack. If the module name
contains a semicolon (`;`), the part before the semicolon
is the module name for mangling, and the part after the
semicolon is the module name for linker directives.
If there is no semicolon, both module names are identical,
and the behavior is the same as before.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
This avoids redundant creation and uniquing of types in the case where
we only have a canonical name. Since the uniquing changes the type
graph this introduced the possibility for use-after-free if
IRGenDebugInfoImpl held on to a direct (non-tracking) DIType *.
rdar://146327709
when creating the members of a struct, to avoid problems when the type
graph changes due to type nodes being uniqued. It's not clear this can
actually happen, but it helps ruling this out as a failure cause.
DBuilder::replaceTemporary() can return a different pointer. In
practice this only happens when temporary and replacement are uniqued,
so that's probably how we got away with this in the past.
This reverts the problematic parts of
fcbebc51c7 which had caused a lot of
unintended fallout, while preserving the actual feature supported by
the patch.
Before that patch (fcbeb), and after this one, we don't emit members
of specialized bound generic types, because these can be reconstructed
by substituting the "template parameters" in the unspecialized
type. This patch carves out an exception for inline arrays, because
DWARF has special support for arrays, which allows debuggers to reason
about them without needing special support.
rdar://146326633
for recursive classes. This is achieved by treating types created with
DebugTypeInfo::createFrowardDecl() as unconditional forward
declarations when emitting debug info instead of applying a heuristic
to determine this.
rdar://146688269
This patch adds support for emitting the flag
llvm::DINode::FlagAllCallsDescribed when generating LLVM IR from the
Swift compiler to get call-site information for swift source code.
This commit also changes how specialized types are being emitted. Previously we
would not emitthe detailed member information in the specialized type itself,
and instead rely on the fact that it was present in the unspecialized type,
however, this wold prevent us from emitting any bound generic members, so we're
now emitting the members in both variants of the type.
This uncovered a with type aliases that this commit also addresses: Because we
don't canonicalize types prior to caching in order to preserve type sugar,
alternative representations of recursive types (with one or more levels of
recursion unfolded) could create potential infinite chains of types. This is
addressed by checking whether a sugared type has an already emitted canonical
representation first, and if yes, creating a typedef node pointing directly to
it.
The donwside of doing this is that it can lead to the disappearnce of type
aliases definitions when they are used as parameters in bound generic
types. However, we still preserve that a type was `MyClass<MyAlias>`. We just
might have a typedef pointing director from `MyClass<MyAlias>` ->
`MyClass<CanonicalType>`.
rdar://144315592
