Summary:
This is a port of D67803 that was about preventing indirect importing to our scratch context when evaluating expressions.
D67803 already has a pretty long explanation of how this works, but the idea is that instead
of importing declarations indirectly over the expression AST (i.e., Debug info AST -> Expression AST -> scratch AST)
we instead directly import the declaration from the debug info AST to the scratch AST.
The difference from D67803 is that here we have to do this in the ASTImporterDelegate (which is our ASTImporter
subclass we use in LLDB). It has the same information as the ExternalASTMerger in D67803 as it can access the
ClangASTImporter (which also keeps track of where Decls originally came from).
With this patch we can also delete the FieldDecl stealing hack in the ClangASTSource (this was only necessary as the
indirect imports caused the creation of duplicate Record declarations but we needed the fields in the Record decl
we originally found in the scratch ASTContext).
This also fixes the current gmodules failures where we fail to find std::vector fields after an indirect import
over the expression AST (where it seems even our FieldDecl stealing hack can't save us from).
Reviewers: shafik, aprantl
Reviewed By: shafik
Subscribers: JDevlieghere, lldb-commits, mib, labath, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72507
GetPersistentExpressionStateForLanguage() can return a nullptr if it
cannot construct a typesystem. This patch adds missing nullptr checks
at all uses.
Inspired by rdar://problem/58317195
Differential Revision: https://reviews.llvm.org/D72413
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
There is no clang::Action anymore so our forward decl for it and the obsolete pointer in the
ASTStructExtractor can both go (that code anyway didn't do anything).
LLDB frequently converts QualType to CompilerType. This is currently done like this:
result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
1. CompilerType's constructor takes a void* pointer so it isn't type safe.
2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
changing it is difficult (e.g., what if we want to just pass the type ptr and not the
1type_ptr | qual_flags1 to CompilerType).
This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.
It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code. This also allows Clang to emit unused variable warnings
for CompilerType, so I also removed one unused variable that otherwise causes -Werror
builds to fail.
We try to build a CompilerType from the persistent decls so we need
a ClangASTContext. With this patch the ClangPersistentVariables store
the associated ClangASTContext of the persistent decls (which is
always the scratch ClangASTContext) and no longer call GetASTContext
to map back from clang::ASTContext to ClangASTContext.
Instead of returning NamedDecls and then calling GetASTContext
to find back the ClangASTContext we used can just implement the
FindDecl variant that returns CompilerDecls (and implement the
other function by throwing away the ClangASTContext part of the
compiler decl).
GetASTContext is really expensive to call as it makes use of the global
mapping from ASTContext to ClangASTContext. This replaces all calls where
we already have the ClangASTContext around and don't need to call
GetASTContext again.
ClangExternalASTSourceCommon's purpose is to store a map from
Decl*/Type* to ClangASTMetadata. Usually this data is accessed
via the ClangASTContext interface which then grabs the
current ExternalASTSource of its ASTContext, tries to cast it
to ClangExternalASTSourceCommon and then accesses the metadata
map. If the casting fails the setter does nothing and the getter
returns a nullptr as if there was no known metadata for a type/decl.
This system breaks as soon as any non-LLDB ExternalASTSource is added via
a multiplexer to our existing ExternalASTSource (in which case we suddenly
loose all out metadata as the casting always fails with an ExternalASTSource
that is not inheriting from ClangExternalASTSourceCommon).
This patch moves the metadata map to the ClangASTContext. This gets
rid of all the fragile casting, the requirement that every ExternalASTSource in
LLDB has to inherit from ClangExternalASTSourceCommon and simplifies
the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon
had no other purpose than storing metadata, this patch deletes this class
and replaces all uses with clang::ExternalASTSource.
No other code changes in this commit beside the AppleObjCDeclVendor which
was the only code that did not use the ClangASTContext interface but directly
accessed the ClangExternalASTSourceCommon.
This adds a check that the ClangASTContext actually fits to the
DeclContext that we want to create a CompilerDeclContext for. If
the ClangASTContext (and its associated ASTContext) does not fit
to the DeclContext (that is, the DeclContext wasn't created by the
ASTContext), all computations using this malformed CompilerDeclContext
will yield unpredictable results.
Also fixes the only place that actually hits this assert which is the
construction of a CompilerDeclContext in ClangExpressionDeclMap
where we pass an unrelated ASTContext instead of the ASTContext
of the current expression.
I had to revert my previous change to DWARFASTParserClangTests.cpp
back to using the unsafe direct construction of CompilerDeclContext
as this assert won't work if the DeclContext we pass isn't a valid
DeclContext in the first place.
The CompilerDeclContext constructor takes a void* pointer which
means that all callers of this constructor need to first explicitly
convert all pointers to clang::DeclContext*. This causes that we
for example can't just pass a TranslationUnitDecl* to the constructor without
first casting it to its parent class (as it inherits from both
Decl and DeclContext so the void* pointer is actually a Decl*).
This patch introduces a utility function in the ClangASTContext
which gets rid of the requirement to cast all pointers to
clang::DeclContext. Also moves all constructor calls to use this
function instead which is NFC (beside the change in
DWARFASTParserClangTests.cpp).
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a
while that the ASTContext is not a nullptr. This causes that we still have a lot of code
that is doing nullptr checks on the result of getASTContext() which is all unreachable code.
This patch changes the return value to a reference to make it clear this can't be a nullptr
and deletes all the nullptr checks.
Their naming is misleading as they only return the
ClangASTContext-owned variables. For ClangASTContext instances constructed
for a given clang::ASTContext they silently generated duplicated instances
(e.g., a second IdentifierTable) that were essentially unusable.
This removes all these getters as they are anyway not very useful in comparison
to just calling the clang::ASTContext getters. The initialization
code has been moved to the CreateASTContext initialization method so that all
code for making our own clang::ASTContext is in one place.
echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'
Actual:
error: Expression can't be run, because there is no JIT compiled function
Expected:
<nothing, sync() has been executed>
This patch has been checked by:
D71707: clang-tidy: new bugprone-pointer-cast-widening
https://reviews.llvm.org/D71707
Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:
echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
<stdin>: In function ‘main’:
<stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000
With debug output:
Actual:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
Code can be run in the target.
Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
Sections:
[0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
...
HandleCommand, command did not succeed
error: Expression can't be run, because there is no JIT compiled function
Expected:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
Code can be run in the target.
Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
Function's code range is [0xb6ff9020+0x40]
...
Function data has contents:
0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
...
Function disassembly:
0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr}
Differential revision: https://reviews.llvm.org/D71498
We already pass a Decl here and the additional ASTContext needs to
match the Decl. We might as well just pass the Decl and then extract
the ASTContext from that.
This adds a unit test for looking up persistent declarations in the scratch AST
context. Also adds the `GetPersistentDecl` hook to the ClangExpressionDeclMap
that this unit test can emulate looking up persistent variables without having
a lldb_private::Target.
The ClangExpressionDeclMap should be testable from a unit test. This is currently
impossible as they have both dependencies on Target/ExecutionContext from their
constructor. This patch allows constructing these classes without an active Target
and adds the missing tests for running without a target that we can do at least
a basic lookup test without crashing.
Summary:
As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup.
This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup
setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around
for now).
The motivation for this is that I don't think that the current approach of implementing modern-type-lookup
will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone
and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has
so far made the transition work much more complicated than it has to be.
A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization
in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly
the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring
and actually testing the existing code we have.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html
Reviewers: shafik, martong
Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71562
The overloads that don't take a CompilerType serve no purpose as we
always have a CompilerType in the scope where we call them. Instead
just call the overload that takes a CompilerType and delete the
now unused other overloaded methods.
Target doesn't really need to know about ClangASTContext more than any
other TypeSystem. We can create a method ClangASTContext::GetScratch for
anything who needs a ClangASTContext specifically instead of just a
generic TypeSystem.
Summary: Not once have I looked at these numbers in a log and considered them useful. Also this should not have been implemented via an unguarded list of globals.
Reviewers: martong, shafik
Reviewed By: shafik
Subscribers: rnkovacs, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71336
This code was just creating a new SymbolContextList with any found functions
in the front and orders them by how close they are to the current frame.
This refactors this code into its own function to make this more obvious.
Doesn't do any other changes to the code, so this is NFC.
ClangASTSource currently takes a clang::ASTContext and keeps that
around, but a lot of LLDB's functionality for doing operations
on a clang::ASTContext is in its ClangASTContext twin class. We
currently constantly recompute the respective ClangASTContext
from the clang::ASTContext while we instead could just pass and
store a ClangASTContext in the ClangASTSource. This also allows
us to get rid of a bunch of unreachable error checking for cases
where recomputation fails for some reason.
Summary:
Adds support for doing range-based for-loops on LLDB's VariableList and
modernises all the index-based for-loops in LLDB where possible.
Reviewers: labath, jdoerfert
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70668
Summary:
LLDB's ASTDumper is just a clone of Clang's ASTDumper but with some scary code and
some unrelated functionality (like dumping name/attributes of types). This removes LLDB's ASTDumper
and replaces its uses with the `ClangUtils::DumpDecl` method that just calls Clang's ASTDumper
and returns the result as a string.
The few uses where we just want a textual representation of a type (which will print their name/attributes but not
dump any AST) are now also in ClangUtil under a `ToString` name until we find a better home for them.
Reviewers: labath
Reviewed By: labath
Subscribers: mgorny, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70663
Searching persistent decls is a small subset of the things
FindExternalVisibleDecls does. It should be its own function instead
of being encapsulated in this `do { } while(false);` pattern.
This overload is only used in one place and having static overloads for
all methods that only do an additional clang::ASTContext -> ClangASTContext
conversion is just not sustainable.
Summary:
This is some really shady code. It's supposed to kick in after an expression already failed and then try to look
up "unknown types" that for some undocumented reason can't be resolved during/before parsing. Beside the
fact that we never mark any type as `EVUnknownType` in either swift-lldb or lldb (which means this code is unreachable),
this code doesn't even make the expression evaluation succeed if if would ever be executed but instead seems
to try to load more debug info that maybe any following expression evaluations might succeed.
This patch removes ClangExpressionDeclMap::ResolveUnknownTypes and the related data structures/checks/calls.
Reviewers: davide
Reviewed By: davide
Subscribers: aprantl, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70388
Builtins are rarely if ever accessed via the Preprocessor. They are
typically found on the ASTContext, so there should be no performance
penalty to using a pointer indirection to store the builtin context.
Three uses of try_lock intentionally ignore the result, as explained in
the comment. Make that explicit with a void cast.
Add what appears to be a missing return in the clang expression parser
code. It's a functional change, but presumably the right one.
Differential Revision: https://reviews.llvm.org/D70281
I wanted to further simplify ParseTypeFromClangModule by replacing the
hand-rolled loop with ForEachExternalModule, and then realized that
ForEachExternalModule also had the problem of visiting the same leaf
node an exponential number of times in the worst-case. This adds a set
of searched_symbol_files set to the function as well as the ability to
early-exit from it.
Differential Revision: https://reviews.llvm.org/D70215
Summary:
swift-lldb currently has to patch the ExpressionKind enum to add support for Swift expressions. If we implement LLVM's RTTI
with a static ID variable instead of a centralised enum we can drop that patch.
Reviewers: labath, davide
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D70070
Summary:
This function is only used internally by ClangExpressionParser. By putting it in the ExpressionParser class all languages
that implement ExpressionParser::Parse have to share the same signature (which forces us in downstream to add
swift-specific arguments to ExpressionParser::Parse which then propagate to ClangExpressionParser and so on).
Reviewers: davide
Subscribers: JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69710
Summary:
Motivated by Swift using the materializer in a few places which requires us to add this getter ourselves.
We also need a setter, but let's keep this minimal to unblock the downstream reverts in Swift.
Reviewers: davide
Reviewed By: davide
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #upstreaming_lldb_s_downstream_patches, #lldb
Differential Revision: https://reviews.llvm.org/D69714
This patch removes the size_t return value and the append parameter
from the remainder of the Find.* functions in LLDB's internal API. As
in the previous patches, this is motivated by the fact that these
parameters aren't really used, and in the case of the append parameter
were frequently implemented incorrectly.
Differential Revision: https://reviews.llvm.org/D69119
llvm-svn: 375160
CppModuleConfiguration is the most likely point of failure when we have weird
setups where we fail to load a C++ module. With this logging it should be easier
to figure out why we can't find a valid configuration as the configuration only
depends on the list of file paths.
llvm-svn: 374350
When playing with the C++ module prototype I noticed I can get LLDB to crash
by making a result type that depends on __make_integer_seq (a BuiltinTemplate)
which is not supported by the ASTImporter yet. This causes the ASTImporter to emit
a diagnostic when copying the type to the ScratchASTContext. As deporting the result
type is done after we are done parsing and the Clang's diagnostic engine asserts that
it can only be used during parsing, it crashes LLDB while trying to render the diagnostic
in the HandleDiagnostic method of ClangDiagnosticManagerAdapter.
This patch just moves the HandleDiagnostic call to Clang behind our check that we still
have a DiagnosticManager (which we remove after parsing) which prevents the assert
from firing. We also shouldn't ignore such diagnostics, so I added a log statement for
them.
There doesn't seem to way to test this as these diagnostic only happen when we copy
a node that's not supported by the ASTImporter which should never happen once
we can copy everything with the ASTImporter, so every test case we add here will
eventually become invalid.
(Note that most of this diff is just whitespace changes as we now use an early exit
instead of a huge 'if' block).
llvm-svn: 374145
Link against clang-cpp dylib rather than split libs when
CLANG_LINK_CLANG_DYLIB is enabled.
Differential Revision: https://reviews.llvm.org/D68456
llvm-svn: 373734
Summary:
As we figured out in D67803, importing declarations from a temporary ASTContext that were originally from a persistent ASTContext
causes a bunch of duplicated declarations where we end up having declarations in the target AST that have no associated ASTImporter that
can complete them.
I haven't figured out how/if we can solve this in the current way we do things in LLDB, but in the modern-type-lookup this is solvable
as we have a saner architecture with the ExternalASTMerger. As we can (hopefully) make modern-type-lookup the default mode in the future,
I would say we try fixing this issue here. As we don't use the hack that was reinstated in D67803 during modern-type-lookup, the test case for this
is essentially just printing any kind of container in `std::` as we would otherwise run into the issue that required a hack like D67803.
What this patch is doing in essence is that instead of importing a declaration from a temporary ASTContext, we instead check if the
declaration originally came from a persistent ASTContext (e.g. the debug information) and we directly import from there. The ExternalASTMerger
is already connected with ASTImporters to these different sources, so this patch is essentially just two parts:
1. Mark our temporary ASTContext/ImporterSource as temporary when we import from the expression AST.
2. If the ExternalASTMerger sees we import from the expression AST, instead of trying to import these temporary declarations, check if we
can instead import from the persistent ASTContext that is already connected. This ensures that all records from the persistent source actually
come from the persistent source and are minimally imported in a way that allows them to be completed later on in the target AST.
The next step is to run the ASTImporter for these temporary expressions with the MinimalImport mode disabled, but that's a follow up patch.
This patch fixes most test failures with modern-type-lookup enabled by default (down to 73 failing tests, which includes the 22 import-std-module tests
which need special treatment).
Reviewers: shafik, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68326
llvm-svn: 373711
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
We have no use case in LLDB where we actually do want to change the ASTContext after
it the ClangASTContext has been constructed. All callers of setASTContext are just setting
the ASTContext directly after construction, so we might as well make this a Constructor
instead of supporting this tricky use case.
llvm-svn: 373330
This was originally a 'do { ... } while (false);' like in the rest
of the function, but the do was refactored into an 'if' without
also removing the trailing 'while(false);'
llvm-svn: 373206
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
There is no ClangModulesDeclVendor on Linux so that cast is triggering an assert.
Let's just remove it as it just casts the type to itself.
llvm-svn: 372974
In top level expressions, we don't have a m_source_code and we don't need to change
the source bounds (as no wrapping happend there). Fixes the test on the
sanitizer bot.
llvm-svn: 372817
Summary:
At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program
and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to
cause a few problems or inconveniences:
* It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible
for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default
(and we can't just close all the associated bug reports).
* Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux).
* We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS).
This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit.
If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module
configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information
than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the
`Darwin` module are their own external type module with their own files).
The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths
based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some
test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism),
but for now it works and makes the feature usable.
Reviewers: aprantl, shafik, jdoerfert
Reviewed By: aprantl
Subscribers: mgorny, abidh, JDevlieghere, lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D67760
llvm-svn: 372716
Summary:
The ClangModulesDeclVendor is currently interpreting all injected `@import` statements in our expression
wrapper as modules that the user has explicitly requested to be persistently loaded. As we inject
`@import` statements with our std module prototype, the ClangModulesDeclVendor will start compiling
and loading unrelated C++ modules because it thinks the user has requested that it should load them. As
the ClangModulesDeclVendor is lacking the setup to compile these modules (e.g. it lacks the include paths),
it will then actually just fail to compile them and cause the whole expression evaluation to fail. This causes
these tests to fail on systems that enable the ClangModulesDeclVendor (such as macOS).
This patch fixes this by preventing the ClangModulesDeclVendor from interpreting `@import` statements
in the wrapper source code. This is done by check if the import happens in the fake source file containing
our wrapper code (which implies it was generated by LLDB).
This patch doesn't reenable the tests as there is more work needed to get the tests running on macOS (D67760)
Reviewers: aprantl, shafik, jingham
Subscribers: lldb-commits
Tags: #c_modules_in_lldb, #lldb
Differential Revision: https://reviews.llvm.org/D61565
llvm-svn: 372690
lvm_private::File::GetStream() can fail if m_options == 0
It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.
This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.
This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67792
llvm-svn: 372652
Summary:
In D61333 we dropped some code from ClangASTSource that checks if imported declarations
ended up in the right DeclContext. While this code wasn't tested by the test suite (or better, it was hit
by the test suite but we didn't have any checks that were affected) and the code seems pointless
(as usually Decls should end up in the right DeclContext), it actually broke the data formatters in LLDB
and causes a bunch of obscure bugs where structs suddenly miss all their members. The first report we got about
this was that printing a std::map doesn't work anymore when simply doing "expr m" (m is the std::map).
This patch reverts D61333 partly and reintroduces the check in a more stricter way (we actually check now that
we *move* the Decl and it is in a single DeclContext). This should fix all the problems we currently have until
we figure out how to properly fix the underlying issues. I changed the order of some std::map formatter tests
which is currently the most reliable way to test this problem (it's a tricky setup, see description below).
Fixes rdar://55502701 and rdar://55129537
--------------------------------------
Some more explanation what is actually going on and what is going wrong:
The situation we have is that if we have a `std::map m` and do a `expr m`, we end up seeing an empty map
(even if `m` has elements). The reason for this is that our data formatter sees that std::pair<int, int> has no
members. However, `frame var m` works just fine (and fixes all following `expr m` calls).
The reason for why `expr` breaks std::map is that we actually copy the std::map nodes in two steps in the
three ASTContexts that are involved: The debug information ASTContext (D-AST), the expression ASTContext
we created for the current expression (E-AST) and the persistent ASTContext we use for our $variables (P-AST).
When doing `expr m` we do a minimal import of `std::map` from D-AST to E-AST just do the type checking/codegen.
This copies std::map itself and does a minimal.import of `std::pair<int, int>` (that is, we don't actually import
the `first` and `second` members as we don't need them for anything). After the expression is done, we take
the expression result and copy it from E-AST to P-AST. This imports the E-AST's `std::pair` into P-AST which still
has no `first` and `second` as they are still undeserialized. Once we are in P-AST, the data formatter tries to
inspect `std::map` (and also `std::pair` as that's what the elements are) and it asks for the `std::pair` members.
We see that `std::pair` has undeserialized members and go to the ExternalASTSource to ask for them. However,
P-ASTs ExternalASTSource points to D-AST (and not E-AST, which `std::pair` came from). It can't point to E-AST
as that is only temporary and already gone (and also doesn't actually contain all decls we have in P-AST).
So we go to D-AST to get the `std::pair` members. The ASTImporter is asked to copy over `std::pair` members
and first checks if `std::pair` is already in P-AST. However, it only finds the std::pair we got from E-AST, so it
can't use it's map of already imported declarations and does a comparison between the `std::pair` decls we have
Because the ASTImporter thinks they are different declarations, it creates a second `std::pair` and fills in the
members `first` and `second` into the second `std::pair`. However, the data formatter is looking at the first
`std::pair` which still has no members as they are in the other decl. Now we pretend we have no declarations
and just print an empty map as a fallback.
The hack we had before fixed this issue by moving `first` and `second` to the first declaration which makes
the formatters happy as they can now see the members in the DeclContext they are querying.
Obviously this is a temporary patch until we get a real fix but I'm not sure what's the best way to fix this.
Implementing that the ClassTemplateSpecializationDecl actually understands that the two std::pair's are the same
decl fixes the issue, but this doesn't fix the bug for all declarations. My preferred solution would be to
complete all declarations in E-AST before they get moved to P-AST (as we anyway have to do this from what I can
tell), but that might have unintended side-effects and not sure what's the best way to implement this.
Reviewers: friss, martong
Reviewed By: martong
Subscribers: aprantl, rnkovacs, christof, abidh, JDevlieghere, lldb-commits, shafik
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67803
llvm-svn: 372549
Summary:
Currently our expression evaluators only prints very basic errors that are not very useful when writing complex expressions.
For example, in the expression below the user made a type error, but it's not clear from the diagnostic what went wrong:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: invalid operands to binary expression ('int' and 'double')
```
This patch enables full Clang diagnostics in our expression evaluator. After this patch the diagnostics for the expression look like this:
```
(lldb) expr printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
error: <user expression 1>:1:54: invalid operands to binary expression ('int' and 'float')
printf("Modulos are:", foobar%mo1, foobar%mo2, foobar%mo3)
~~~~~~^~~~
```
To make this possible, we now emulate a user expression file within our diagnostics. This prevents that the user is exposed to
our internal wrapper code we inject.
Note that the diagnostics that refer to declarations from the debug information (e.g. 'note' diagnostics pointing to a called function)
will not be improved by this as they don't have any source locations associated with them, so caret or line printing isn't possible.
We instead just suppress these diagnostics as we already do with warnings as they would otherwise just be a context message
without any context (and the original diagnostic in the user expression should be enough to explain the issue).
Fixes rdar://24306342
Reviewers: JDevlieghere, aprantl, shafik, #lldb
Reviewed By: JDevlieghere, #lldb
Subscribers: usaxena95, davide, jingham, aprantl, arphaman, kadircet, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65646
llvm-svn: 372203
This reverts commit 21641a2f6d.
It was causing the following test failures:
lldb-Suite.lang/objc/objc-class-method.TestObjCClassMethod.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsString.py
lldb-Suite.lang/objc/foundation.TestConstStrings.py
lldb-Suite.lang/objc/radar-9691614.TestObjCMethodReturningBOOL.py
lldb-Suite.lang/objc/foundation.TestObjCMethodsNSArray.py
llvm-svn: 372057
We never compare these directories (where ConstString would be good) and
essentially just convert this back to a normal string in the end. So we might
as well just use std::string. Also makes it easier to unittest this code
(which was the main motivation for this change).
llvm-svn: 371623
LLVMUserExpression doesn't use these variables and they are all specific to Clang.
Also removes m_const_object as this was actually never used by anyone (and Clang
didn't report it as we assigned it in the constructor which seems to count as use).
llvm-svn: 370440
This reverts commit r367842 since it wasn't quite as NFC as advertised
and broke Swift support. See https://reviews.llvm.org/D46083 for the
rationale behind the original functionality.
rdar://problem/54619322
llvm-svn: 370126
Summary:
This removes DeclVendor's dependency on clang (and ClangASTContext).
DeclVendor has no need to know about specific TypeSystems.
Differential Revision: https://reviews.llvm.org/D66628
llvm-svn: 369735
Summary:
This introduces a layer between DeclVendor and the currently implemented
DeclVendors (ClangModulesDeclVendor and AppleObjCDeclVendor). This
allows the removal of DeclVendor::GetImporterSource which is extremely
clang-specific, freeing up the interface to be more general.
A good follow up to this would be to remove the remaining instances of
clang in DeclVendor, either by moving things to ClangDeclVendor or by
using wrappers (e.g. CompilerDecl instead of clang::NamedDecl).
Differential Revision: https://reviews.llvm.org/D66451
llvm-svn: 369424
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368933
It seems this breaks the following tests:
lldb-Suite :: expression_command/call-function/TestCallUserDefinedFunction.py
lldb-Suite :: expression_command/rdar42038760/TestScalarURem.py
Let's revert this patch and wait until we find an actual issue that could be
fixed by also doing the guard variable check on Windows.
llvm-svn: 368920
The isGuardVariableSymbol option for ignoring Microsoft's ABI
was originally added to get the bots green, but now that we found
the actual issue (that we checked for prefix instead of suffix
in the MS ABI check), we should be able to properly implement
the guard variable check without any strange Microsoft exceptions.
llvm-svn: 368802
Summary:
Ideally CompilerType would have no knowledge of clang or any individual
TypeSystem. Decoupling clang is relatively straightforward.
Differential Revision: https://reviews.llvm.org/D66102
llvm-svn: 368741
It seems the broken guard variable check for Windows was a feature(TM)
and not a bug, so let's keep add a flag to the guard check that keeps
the old behavior in the places where we ignored guard variables before.
llvm-svn: 368688
Summary:
And not `zero`. This is the last API needed to be converted to
an Optional<T>.
Reviewers: xiaobai, compnerd
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66093
llvm-svn: 368614
Summary:
Our IR rewriting infrastructure currently fails when it encounters a variable which has no metadata associated.
This causes dynamic_cast to fail as in this case IRForTarget considers the type info pointers ('@_ZTI...') to be
variables without associated metadata. As there are no variables for these internal variables, this is actually
not an error and dynamic_cast would work fine if we didn't throw this error.
This patch fixes this by removing this diagnostics code. In case we would actually hit a variable that has no
metadata (but is supposed to have), we still have the error in the expression log so this shouldn't make it
harder to diagnose any missing metadata errors.
This patch should fix dynamic_cast and also adds a bunch of test coverage to that language feature.
Fixes rdar://10813639
Reviewers: davide, labath
Reviewed By: labath
Subscribers: friss, labath, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65932
llvm-svn: 368511
Not NFC as this will probably fix a wrong guard variable check
on Windows. Not sure though what Windows test can now be safely
enabled.
llvm-svn: 368417
Summary:
After rL368069 I noticed that HAVE_SYS_TYPES_H is not defined in
Platform.h, or anywhere else in lldb. This change fixes that.
Reviewers: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D65822
llvm-svn: 368125
After the recent refactorings the SymbolVendor passthrough no longer
serve any purpose. This patch removes those methods, and updates all
callsites to go to the symbol file directly -- in most cases that just
means calling GetSymbolFile()->foo() instead of
GetSymbolVendor()->foo().
llvm-svn: 368001
The UpdateLanguageForExpr should only update the language, but over
time it started to do also do different things related to the generation
of the expression source code. This patch refactors all the source code
generation part into its own function.
llvm-svn: 367922
Currently Target::m_next_persistent_variable_index is counting up
for our persistent variables ($0, $1, ...) but we also have a
unused counter that is supposed to do this in
ClangPersistentVariables but that stays always at 0 (because
we currently increase the target counter when we should increase
that unused counter).
This patch removes the counter in Target and lets the documented
counter in ClangPersistentVariables do the variable counting.
Patch *should* be NFC, but it might unexpectedly bring LLDB to
new code paths that could contain exciting new bugs to fix.
llvm-svn: 367842
Summary:
Currently, clang's FileManager uses NULL as an indicator that a particular file
did not exist, but would not propagate errors like permission issues. Instead,
teach FileManager to use llvm::ErrorOr internally and return rich errors for
failures.
Reviewers: arphaman, bruno, martong, shafik
Subscribers: nemanjai, kbarton, MaskRay, jkorous, dexonsmith, kadircet, jsji, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D65534
llvm-svn: 367618
Summary:
This commit achieves the following:
- Functions used to return a `TypeSystem *` return an
`llvm::Expected<TypeSystem *>` now. This means that the result of a call
is always checked, forcing clients to move more carefully.
- `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a
non-null pointer to a TypeSystem.
Reviewers: JDevlieghere, davide, compnerd
Subscribers: jdoerfert, lldb-commits
Differential Revision: https://reviews.llvm.org/D65122
llvm-svn: 367360
Instead of passing the FileCollector around as a reference or raw
pointer, use a shared_ptr. This change's motivation is twofold. First it
adds compatibility for the newly added `FileCollectorFileSystem`.
Secondly, it addresses a lifetime issue we only see when LLDB is used
from Xcode, where a reference to the FileCollector outlives the
reproducer instance.
llvm-svn: 367258
The FileCollector got lifted into LLVM and a shim was introduced in LLDB
to keep the old API that takes FileSpecs. This patch removes that shim
and converts the arguments in place.
llvm-svn: 366975
This patch changes the coding style of the FileCollector from the LLDB
to the LLVM coding style. Alex recently lifted it into LLVM and I
volunteered to do the conversion.
llvm-svn: 366966
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
This fixes the unchecked-error assertion at runtime.
Expected<T> must be checked before access or destruction. Expected<T>
value was in success state. (Note: Expected<T> values in success mode
must still be checked prior to being destroyed).
llvm-svn: 366853
Summary:
We assume in LLDB that every type comes from an ASTContext with an associated ClangASTContext.
However the types inside the ClangModuleDeclVendor don't have a ClangASTContext so we end up
crashing whenever we create a CompilerType for one of these types.
Simplest way to trigger this bug is to just look up NSObject from a module:
(lldb) expr @import Foundation
(lldb) type lookup NSObject
Assertion failed: (m_type_system != nullptr), function CompilerType, file /Users/teemperor/llvm1/llvm-project/lldb/source/Symbol/CompilerType.cpp, line 39.
This patch just creates a ClangASTContext for the ASTContext used by ClangModuleDeclVendor.
Reviewers: davide, shafik
Reviewed By: davide
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64989
llvm-svn: 366653
Summary:
We currently don't support offsetof in the expression evaluator as it is implemented as a macro
(which then calls __builtin_offsetof) in stddef.h. The best solution would be to include that
header (or even better, import Clang's builtin module), but header-parsing and
(cross-platform) importing modules is not ready yet.
Until we get this working with modules I would say we add the macro to our existing macro list
as we already do with other macros from stddef.h/stdint.h. We should be able to drop all of them
once we can import the relevant modules by default.
rdar://26040641
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: clayborg, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64917
llvm-svn: 366476
Summary:
Currently the ClangModulesDeclVendor is spamming the expression log with the compiler flags it is using, which creates a log that looks like this:
```
clang
-fmodules
-fimplicit-module-maps
```
This patch removes all these newlines and just prints the compiler flags in one line as you see in the command line:
```
clang -fmodules -fimplicit-module-maps [...]
```
Reviewers: shafik, davide
Reviewed By: davide
Subscribers: davide, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64858
llvm-svn: 366347
Summary:
With LLDB we use localUncachedLookup(), however, that fails to find
Decls when a transparent context is involved and the given DC has
external lexical storage. The solution is to use noload_lookup, which
works well with transparent contexts. But, we cannot use only the
noload_lookup since the slow case of localUncachedLookup is still needed
in some other cases.
These other cases are handled in ASTImporterLookupTable, but we cannot
use that with LLDB since that traverses through the AST which initiates
the load of external decls again via DC::decls().
We must avoid loading external decls during the import becuase
ExternalASTSource is implemented with ASTImporter, so external loads
during import results in uncontrolled and faulty import.
Reviewers: shafik, teemperor, jingham, clayborg, a_sidorin, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61333
llvm-svn: 366325
Summary:
Following up to my CPPLanguageRuntime change, I'm moving
ObjCLanguageRuntime into a plugin as well.
Reviewers: JDevlieghere, compnerd, jingham, clayborg
Subscribers: mgorny, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D64763
llvm-svn: 366148
Summary: This seems better suited to be in a plugin.
Reviewers: JDevlieghere, clayborg, jingham, compnerd, labath
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64599
llvm-svn: 365951
Summary:
IRDynamicChecks in its current form is specific to Clang since it deals
with the C language family. It is possible that we may want to
instrument code generated for other languages, but we can factor in a
more general mechanism to do so at a later time.
This decouples ObCLanguageRuntime from Expression!
Reviewers: compnerd, clayborg, jingham, JDevlieghere
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D64591
llvm-svn: 365853
Summary:
I saw while debugging that we call this file `ParseInternal`, which is not a very good name for our
fake expression file and also adds this unnecessary link between the way we name this function
and the other source location names we get from the expression parser. This patch is renaming
it to `<lldb-expr>` which is closer to the way Clang names its buffers, it doesn't depend on the
function name (which changes when I refactor this code) and it's easier to grep for.
Reviewers: davide
Reviewed By: davide
Subscribers: abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D64545
llvm-svn: 365812
Summary:
this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html
with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration.
Changes:
- add the consteval keyword.
- add parsing of consteval specifier for normal declarations and lambdas expressions.
- add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval.
- adapt diagnostic about constexpr to print constexpr or consteval depending on the case.
- add tests for basic semantic.
Reviewers: rsmith, martong, shafik
Reviewed By: rsmith
Subscribers: eraman, efriedma, rnkovacs, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61790
llvm-svn: 363362
Summary:
PersistentStateExpressions (e.g. ClangPersistentVariables) have the
ability to define types using expressions that persist throughout the
debugging session. GetCompilerTypeFromPersistentDecl is a useful
operation to have if you need to use any of those persistently declared types,
like in CommandObjectMemory.
This decouples clang from CommandObjectMemory and decouples Plugins from
Commands in general.
Differential Revision: https://reviews.llvm.org/D62797
llvm-svn: 363183
Summary:
In an effort to make Process more language agnostic, I removed
GetCPPLanguageRuntime from Process. I'm following up now with an equivalent
change for ObjC.
Differential Revision: https://reviews.llvm.org/D63052
llvm-svn: 362981
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
Summary:
This is the final phase of the refactoring towards using llvm::Expected
and llvm::Error in the ASTImporter API.
This involves the following:
- remove old Import functions which returned with a pointer,
- use the Import_New functions (which return with Err or Expected) everywhere
and handle their return value
- rename Import_New functions to Import
This affects both Clang and LLDB.
Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin
Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits
Tags: #clang, #lldb
Differential Revision: https://reviews.llvm.org/D61438
llvm-svn: 360760
Raphael Isemann