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
Summary:
The change https://reviews.llvm.org/D55575 modified ClangASTContext::CreateParameterDeclaration to call decl_ctx->addDecl(decl); this caused a regression since the existing code in DWARFASTParserClang::ParseChildParameters is called with the containing DeclContext. So when end up with cases where we are parsing a parameter for a member function and the parameter is added to the CXXRecordDecl as opposed to the CXXMethodDecl. This example is given in the regression test TestBreakpointInMemberFuncWNonPrimitiveParams.py which without this fix in a modules build leads to assert on setting a breakpoint in a member function with non primitive parameters. This scenario would be common when debugging LLDB or clang.
Differential Revision: https://reviews.llvm.org/D65414
llvm-svn: 367726
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
Add a function to flatten the nested aggregate type
Differential Revision: https://reviews.llvm.org/D62702
Patch by Wanyi Ye <kusmour@gmail.com>
llvm-svn: 362543
Summary:
In r259902, LLDB started injecting all the locals in every expression
evaluation. This fixed a bunch of issues, but also caused others, mostly
performance regressions on some codebases. The regressions were bad
enough that we added a setting in r274783 to control the behavior and
we have been shipping with the setting off to avoid the perf regressions.
This patch changes the logic injecting the local variables to only inject
the ones present in the expression typed by the user. The approach is
fairly simple and just scans the typed expression for every local name.
Hopefully this gives us the best of both world as it just realizes the
types of the variables really used by the expression.
Landing this requires the 2 other issues I pointed out today to be addressed
but I wanted to gather comments right away.
Original patch by Frédéric Riss!
Reviewers: jingham, clayborg, friss, shafik
Reviewed By: jingham, clayborg
Subscribers: teemperor, labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D46551
llvm-svn: 359773
Summary:
When we encounter a templated function in the debug information, we
were creating an AST that looked like this:
FunctionTemplateDecl 0x12980ab90 <<invalid sloc>> <invalid sloc> foo<int>
|-TemplateTypeParmDecl 0x12980aad0 <<invalid sloc>> <invalid sloc> class depth 0 index 0 T
|-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
| |-TemplateArgument type 'int'
| `-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
`-FunctionDecl 0x12980aa30 <<invalid sloc>> <invalid sloc> foo<int> 'int (int)' extern
|-TemplateArgument type 'int'
`-ParmVarDecl 0x12980a998 <<invalid sloc>> <invalid sloc> t1 'int'
Note that the FunctionTemplateDecl has 2 children which are identical (as
in have the same address). This is not what Clang is doing:
FunctionTemplateDecl 0x7f89d206c6f8 </tmp/template.cpp:1:1, line:4:1> line:2:5 foo
|-TemplateTypeParmDecl 0x7f89d206c4a8 <line:1:10, col:19> col:19 referenced typename depth 0 index 0 T
|-FunctionDecl 0x7f89d206c660 <line:2:1, line:4:1> line:2:5 foo 'int (T)'
| `-ParmVarDecl 0x7f89d206c570 <col:9, col:11> col:11 t1 'T'
`-FunctionDecl 0x7f89d206cb60 <line:2:1, line:4:1> line:2:5 used foo 'int (int)'
|-TemplateArgument type 'int'
`-ParmVarDecl 0x7f89d206ca68 <col:9, col:11> col:11 t1 'int':'int'
The 2 chidlren are different and actually repesent different things: the first
one is the unspecialized version and the second one is specialized. (Just looking
at the names shows another major difference which is that we create the parent
with a name of "foo<int>" when it should be just "foo".)
The fact that we have those 2 identical children confuses the ClangImporter
and generates an infinite recursion (reported in https://llvm.org/pr41473).
We cannot create the unspecialized version as the debug information doesn't
contain a mapping from the template parameters to their use in the prototype.
This patch just creates 2 different FunctionDecls for those 2 children of the
FunctionTemplateDecl. This avoids the infinite recursion and allows us to
call functions. As the XFAILs in the added test show, we've still got issues
in our handling of templates. I believe they are mostly centered on the fact
that we create do not register "foo" as a template, but "foo<int>". This is
a bigger change that will need changes to the debug information generation.
I believe this change makes sense on its own.
Reviewers: shafik, clayborg, jingham
Subscribers: aprantl, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D61044
llvm-svn: 359140
Add a convenience 'expectedFailureNetBSD' decorator and mark all tests
currently failing on NetBSD with it. Also skip a few tests that hang
the test suite. This should establish a baseline for the test suite
and get us closer to enabling tests on buildbot. This will help us
catch regressions while we still have a lot of work to do to get tests
working.
It seems that there are also some flaky tests. I am going to address
them later on.
Differential Revision: https://reviews.llvm.org/D58527
llvm-svn: 355320
test/lang/cpp/class-template-parameter-pack/TestClassTemplateParameterPack.py
It fails on Mac OS; apparently a VarDecl 'void *&C' is implicitly
declared there, making the class template name C ambiguous.
llvm-svn: 354185
This patch properly extracts the full submodule path as well as its
search paths from DWARF import decls and passes it on to the
ClangModulesDeclVendor.
rdar://problem/47970144
Differential Revision: https://reviews.llvm.org/D58090
llvm-svn: 353961
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
This patch changes the behavior when printing C++ function references:
where we previously would get a <could not determine size>, there is
now a <no summary available>. It's not clear to me whether this is a
bug or an omission, but it's one step further than LLDB previously
got.
Differential Revision: https://reviews.llvm.org/D56798
llvm-svn: 351376
This is a set of tests that were all marked as failing becuse of pr24764. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349719
This is a set of tests that were all marked as failing becuse of several different bugs. A couple of the bugs are now resolved as fixed since all the tests that were failing associated with the bug are now passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349711
This is a set of tests that were all marked as failing becuse of pr21765. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349668
This is a set of tests that were all marked as failing becuse of pr24489. The bug is not fixed (as in more of the tests that were marked this way are failing), but this set is passing. It is possible that some of them are false positives, but there's a large number of unexpectedly passing tests on Windows, so I am doing a bulk un-xfail to get the buildbot to green.
llvm-svn: 349665
These tests are now passing on linux, at least with top-of-tree clang,
clang-6 and gcc-7.3. It's possible it may still be failing with some
older compilers, but I don't have those around to test.
llvm-svn: 349478
Due to some libcxx changes to inlining, this now also crashes,
so it gets reported as "failure" by the bot. This commit doesn't
really change the status quo, just placates the bots.
llvm-svn: 345668
This applies the same workaround as r321271 to other tests. The root
problem is that lldb finds an internal symbol with the same name in the
debug info of system libraries, and then fails to disambiguate between
the two.
llvm-svn: 341235
Summary:
1) Several tests that are flakey on windows fail the run even if they are marked as expected to be flakey. This is because they fail frequently enough that even a retry won't help
2) Skip several tests on Windows that will occasionally hang rather than failing or exiting. This is causing the entire test suite to hang
Reviewers: asmith, labath, zturner
Reviewed By: zturner
Differential Revision: https://reviews.llvm.org/D50198
llvm-svn: 338769
Summary:
The test suite has often unnecessary trailing whitespace, and sometimes
unnecessary trailing lines or a missing final new line. This patch just strips
trailing whitespace/lines and adds missing newlines at the end.
Subscribers: ki.stfu, JDevlieghere, christof, lldb-commits
Differential Revision: https://reviews.llvm.org/D49943
llvm-svn: 338171
Summary: It looks like the test file was copied from TestCPPStaticMethods.py because they have the same name. This means that the two tests will try to write to the same output files and will either overwrite each other's output or occasionally cause failures because they can't both access the same file.
Reviewers: asmith, zturner
Reviewed By: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49261
llvm-svn: 336960
Summary:
1) When ReadRegister is called with a null register into on Windows, rather than crashing due to an access violation, simply return false. Not all registers and properties will be read or calculated correctly, but that is consistent with other platforms that also return false in that case
2) Update a couple of tests to reference pr37995 as their reason for failure since it is much more accurate. Support for floating point registers doesn't exist on Windows at all, rather than having issues.
Reviewers: asmith, labath, zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D48844
llvm-svn: 336147
libstdc++ will soon be dropped from the android NDK. This patch makes
sure we are prepared for that by using libc++ in tests by default (i.e.,
except for libstdc++ data formatter tests).
Only a couple of small tweaks were needed to make this work:
- Add the libc++ include paths to CXXFLAGS only. This was necessary to
make the tests compile with -fmodules. The modules tests have been
disabled, but this way, they will be ready for them if they are
enabled.
- in one test I had to add an explicit std::string copy to make sure the
copy constructor is there for the expression evaluator to find it.
llvm-svn: 335344
In a modules build, android is very picky about which symbols are
visible after including libc++ headers (e.g. <cstdio> defines only
std::printf and not ::printf).
This consolidates the tests where this was an issue to always include
the <c???> version of the headers and prefixes the symbols with std:: as
necessary.
Apart from that, there is no functional change in the tests.
llvm-svn: 335149
Apparently some compilers generate incomplete debug information which
caused the updated test to fail. Therefore I've extracted the new check
into a separate test case with the necessary decorators.
llvm-svn: 334456
Before Pavel's change in r334181, we were printing too many global
variables. This patch updates the test suite to ensure we don't regress
again in the future.
rdar://problem/29180927
llvm-svn: 334454
Summary: They all correspond to bugs that are already logged and I've added the appropriate (or most appropriate) bug numbers. This leaves only a handful of failing tests.
Reviewers: asmith, zturner, labath
Reviewed By: zturner
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D47892
llvm-svn: 334210
Summary:
... and fix one bug found this way. Currently, the test works not because
types are looked up correctly, but because by injecting local variables
we also materialize the types for Clang. If we disable the local variable
injection, then one check fails.
The reason of the failure is that FindTypes is run with max_matches==1
and this value is passed down to the symbol lookup functions. When the
search is performed only on the basename (like it's the case for an
entity defined in the root namespace), then the search will stop after
having found one match on the basename. But that match might be in a
namespace, we were really just looking up the basename in the accelerator
tables.
The solution is to not pass max_matches down, but to search without a
limit and let RemoveMismatchedTypes do its job afterwards. Note the
patch includes 2 hunks with the same change, but only the latter is
tested. I couldn't find a way to create a testcase for the other
branch of the if ('image lookup -t' allows me to get there, but it
only ever returns one type anyway).
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46548
llvm-svn: 331719
This patch fixes an issue where we weren't looking for exact matches in the expression parser and also fixed the type lookup logic in the Module.cpp. Tests added to make sure we don't regress.
Differential Revision: https://reviews.llvm.org/D46128
llvm-svn: 331227
The isOverload() method needs to account for situations where the two
methods being compared don't have the same number of arguments.
rdar://problem/39542960
llvm-svn: 330450
