A workaround in codeview debuginfo generation was to declare a condfail
instruction as inlined to avoid using 0 as an artificial line location.
However, this was done without accounting for scopes that were already
legitimately inlined. So we'd end up with a condfail inlined from
function B into function A and then the IRGen for the condfail was
being given a debugloc claiming to have been inlined again. This was
causing a sitaution where we'd have debug info forfunctionA owning an
instruction which claimed it was owned by a different function.
Fix this by first checking if the `LastScope` was already inlined and,
if so, just used that scope instead.
When a Swift module built with debug info imports a library without
debug info from a textual interface, the textual interface is
necessary to reconstruct types defined in the library's interface. By
recording the Swift interface files in DWARF dsymutil can collect them
and LLDB can find them.
rdar://problem/49751363
module imports. This is useful when building redistributable static
archives, since any pointers into the CLang module cache won't be
portable.
When using this option the Clang type fallback path in LLDB will be
less useful since DWARF type information from those modules will not
be available unless another object file compiled without the option
imported the same modules.
rdar://problem/48827784
This is an attribute that gets put on an import in library FooKit to
keep it from being a requirement to import FooKit. It's not checked at
all, meaning that in this form it is up to the author of FooKit to
make sure nothing in its API or ABI depends on the implementation-only
dependency. There's also no debugging support here (debugging FooKit
/should/ import the implementation-only dependency if it's present).
The goal is to get to a point where it /can/ be checked, i.e. FooKit
developers are prevented from writing code that would rely on FooKit's
implementation-only dependency being present when compiling clients of
FooKit. But right now it's not.
rdar://problem/48985979
...in preparation for me adding a third kind of import, making the
existing "All" kind a problem. NFC, except that I did rewrite the
ClangModuleUnit implementation of getImportedModules to be simpler!
It would be nice to query the clang::SourceManager for the source
location of the clang::Decl in IRGenDebugInfo, but module out-of-date
rebuilds may unload previously loaded clang::Modules and thus also
invalidate source locations pointed to, leading to a use-after-free
here. If this functionality is desired, the source location must be
captured by ClangImporter and stored on the side.
LLDB does not actually make use of this information for non-C++ types
(it is really helpful with debugging the debug info itself, though),
so we can avoid the potential use-after-free and crash by not doing it.
<rdar://problem/48509051>
Currently LLDB calls into ide::getDeclFromMangledSymbolName() to get
to this information and we would like to get rid of this call.
rdar://problem/47798056
The getLocStart API is deprecated and slated for removal from LLVM
very soon. Switch to use getBeginLoc instead. I did not see any uses
of the corresponding getLocEnd API.
This applies the same changes from Clang CFE r349065 to the Swift
frontend to unify how filenames, cmpilation directories and absolute
paths in filenames and path remappings are handled.
Add an IRGen flag to disable this verification, since it doesn't work from within
lldb itself for some reason, and I don't want to investigate it right now.
The loading of additional modules by Sema may trigger an out-of-date
PCM rebuild in the Clang module dependencies of the additional
module. A PCM rebuild causes the ModuleManager to unload previously
loaded ASTFiles. For this reason we must use the cached ASTFile
information here instead of the potentially dangling pointer to the
ASTFile that is stored in the clang::Module object.
This fixes a crash in IRGenDebugInfo when generation DIModule context
chains.
rdar://problem/47600180
Context archetypes and opened existential archetypes differ in a number of details, and this simplifies the overlapping storage of the kind-specific fields. This should be NFC; for now, this doesn't change the interface of ArchetypeType, but should allow some refinements of how the special handling of certain archetypes are handled.
For a yet-to-be-determined reason the Clang SourceManager returns
source file paths with a ./ component before the filename if the
module cache is cold.
<rdar://problem/43439465>
While stepping through Swift programs in LLDB I noticed that sometimes
the line table entries go like this:
foo(bar(baz)) // Some auxiliary code for the entire expression.
^
foo(bar(baz))
^
foo(bar(baz)) // And then back again for that actual call to foo.
^
This verification step is aimed at identifying situations like this so
they can be fixed.
Most of this patch is just removing special cases for materializeForSet
or other fairly mechanical replacements. Unfortunately, the rest is
still a fairly big change, and not one that can be easily split apart
because of the quite reasonable reliance on metaprogramming throughout
the compiler. And, of course, there are a bunch of test updates that
have to be sync'ed with the actual change to code-generation.
This is SR-7134.
This makes it easier to grep for and eventually remove the
remaining usages.
It also allows you to write FunctionType::get({}, ...) to call the
ArrayRef overload empty parameter list, instead of picking the Type
overload and calling it with an empty Type() value.
While I"m at it, in a few places instead of renaming just clean up
usages where it was completely mechanical to do so.
- getAsDeclOrDeclExtensionContext -> getAsDecl
This is basically the same as a dyn_cast, so it should use a 'getAs'
name like TypeBase does.
- getAsNominalTypeOrNominalTypeExtensionContext -> getSelfNominalTypeDecl
- getAsClassOrClassExtensionContext -> getSelfClassDecl
- getAsEnumOrEnumExtensionContext -> getSelfEnumDecl
- getAsStructOrStructExtensionContext -> getSelfStructDecl
- getAsProtocolOrProtocolExtensionContext -> getSelfProtocolDecl
- getAsTypeOrTypeExtensionContext -> getSelfTypeDecl (private)
These do /not/ return some form of 'this'; instead, they get the
extended types when 'this' is an extension. They started off life with
'is' names, which makes sense, but changed to this at some point. The
names I went with match up with getSelfInterfaceType and
getSelfTypeInContext, even though strictly speaking they're closer to
what getDeclaredInterfaceType does. But it didn't seem right to claim
that an extension "declares" the ClassDecl here.
- getAsProtocolExtensionContext -> getExtendedProtocolDecl
Like the above, this didn't return the ExtensionDecl; it returned its
extended type.
This entire commit is a mechanical change: find-and-replace, followed
by manual reformatted but no code changes.
Joe Groff
Adrian Prantl
Nathan Lanza
adrian-prantl
swift-ci
Jordan Rose
David Goldman
Slava Pestov
Bob Wilson
Saleem Abdulrasool
Robert Widmann
Parker Schuh
Davide Italiano
John McCall