summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lang
Commit message (Collapse)AuthorAgeFilesLines
* A third attempt to mark TestRdar12408181.py as skippedVedant Kumar2018-01-171-1/+3
| | | | | | | | | | | | | Due to an unfortunate difference between the open source test harness and our internal harness, applying two @skip... decorators to this test works in the internal build but not in the open source build. I've tried another approach to skipping this test and tested it out with the open source harness. Hopefully this sticks! rdar://36417163 llvm-svn: 322756
* Try again to mark TestRdar12408181.py as skippedVedant Kumar2018-01-171-3/+7
| | | | | | rdar://36417163 llvm-svn: 322740
* Skip a flaky test (TestRdar12408181.py)Vedant Kumar2018-01-171-1/+3
| | | | | | | | | | This test frequently times out on our bots. While we're investigating the issue, mark the test as skipped so the builds aren't impacted as much. rdar://36417163 llvm-svn: 322728
* Skip TestFunctionTemplateParameterPack.py, which unexpectedly asserts (PR35920)Vedant Kumar2018-01-121-1/+7
| | | | | | | | | | This test stresses expression evaluation support for template functions. Currently the support is rudimentary, and running this test causes assertion failures in clang. This test cannot be XFAIL'ed because the test harness treats assertion failures as unexpected events. For now, the test must be skipped. llvm-svn: 322340
* TestConflictingSymbols: simplify test by using run_break_set_by_source_regexpPavel Labath2018-01-091-14/+8
| | | | | | follow-up to r321271 based on post-commit feedback by Jim Ingham. llvm-svn: 322075
* Look for external types in all clang modules imported by the current symbol ↵Adrian Prantl2018-01-047-0/+51
| | | | | | | | | | | | | file. This fixes a bug in -gmodules DWARF handling when debugging without a .dSYM bundle that was particularly noticable when debugging LLVM itself. Debugging without clang modules and DWO handling should be unaffected by this patch. <rdar://problem/32436209> llvm-svn: 321802
* Work around test failures on red-hat linuxPavel Labath2017-12-212-7/+40
| | | | | | | | | | | | | | | | Two tests were failing because the debugger was picking up multiply defined internal symbols from the system libraries. This is a bug, as there should be no ambiguity because the tests are defining variables with should shadow these symbols, but lldb is not smart enough to figure that out. I work around the issue by renaming the variables in these tests, and in exchange I create a self-contained test which reproduces the issue without depending on the system libraries. This increases the predictability of our test suite. llvm-svn: 321271
* [testsuite] Un-XFAIL the global variables tests.Davide Italiano2017-12-171-6/+0
| | | | | | | | <rdar://problem/28725399> Differential Revision: https://reviews.llvm.org/D41312 llvm-svn: 320952
* [TestModulesInlineFunctions] This test now passes.Davide Italiano2017-12-121-1/+0
| | | | | | | | | Remove yet another spurious unexpected success. Ack'ed by Jim Ingham. Fixes PR25743. llvm-svn: 320454
* [TestCppScope] This test now passes on Darwin.Davide Italiano2017-12-121-5/+0
| | | | | | | | | I tested on x86-64 and Jason on embedded architectures. This cleans up another couple of reported unexpected successes. <rdar://problem/28623427> llvm-svn: 320452
* Rollback [Testsuite] Rename this file from *m -> *mm.Davide Italiano2017-12-121-0/+0
| | | | | | | | After discussing this with Jim and Jason, I think my commit was actually sweeping the issue under the carpet rather than fixing it. I'll take a closer look between tonight and tomorrow. llvm-svn: 320447
* [testsuite] Remove testing failures vestiges.Davide Italiano2017-12-121-60/+0
| | | | | | | | | | | | | | | | | Some tests are failing on macOS when building with the in-tree clang, and this is because they're conditional on the version released. Apple releases using a different versioning number, but as these are conditional on clang < 7, they fail for clang ToT (which is 6.0). As a general solution, we actually need either a mapping between Apple internal release version and public ones. That said, I discussed this with Fred , and Apple Clang 6.0 seems to be old enough that we can remove this altogether (which means I can delay implementing the general purpose solution for a bit). Differential Revision: https://reviews.llvm.org/D41101 llvm-svn: 320444
* [Testsuite] Rename this file from *m -> *mm.Davide Italiano2017-12-111-0/+0
| | | | | | | | Should hopefully bring the bots back. <rdar://problem/35976115> llvm-svn: 320422
* Makefile.rules: compile all tests with -fno-limit-debug-infoPavel Labath2017-12-043-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This flag is on by default for darwin and freebsd, but off for linux. Without it, clang will sometimes not emit debug info for types like std::string. Whether it does this, and which tests will fail because of that depends on the linux distro and c++ library version. A bunch of tests were already setting these flags manually, but here instead I take a whole sale approach and enable this flag for all tests. Any test which does not want to have this flag (right now we have one such test) can turn it off explicitly via CFLAGS_EXTRAS+=$(LIMIT_DEBUG_INFO_FLAGS) This fixes a bunch of data formatter tests on red-hat. Reviewers: davide, jankratochvil Subscribers: emaste, aprantl, krytarowski, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D40717 llvm-svn: 319653
* Support scoped enums in the DWARF AST parserTamas Berghammer2017-11-071-2/+2
| | | | | | | | Subscribers: JDevlieghere Differential Revision: https://reviews.llvm.org/D39545 llvm-svn: 317563
* Disable tests in lang/c/shared_lib on WindowsStephane Sezer2017-11-071-0/+3
| | | | | | | | | | | | | | Summary: These fail because `-fPIC` is not supported on Windows. Reviewers: zturner, jingham, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D39692 llvm-svn: 317529
* Remove getCategories mechanism of specifying test categoriesPavel Labath2017-11-024-11/+3
| | | | | | | | | | | | | | | | | | Summary: This mechanism was mostly redundant with the file-based .categories mechanism, and it was interfering with it, as any test which implemented a getCategories method would not inherit the filesystem categories. This patch removes it. The existing categories are preserved either by adding a .categories file, or using the @add_test_categories decorator. Reviewers: jingham, clayborg, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D39515 llvm-svn: 317277
* Add support for running the lldb testsuite against an apple watchJason Molenda2017-09-273-0/+6
| | | | | | | | running watchos. These tests cannot run on normal customer devices, but I hope to some day have a public facing bot running against a device. llvm-svn: 314355
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-259-19/+58
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these tests, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314132
* Revert "Initial patchset to get the testsuite running against armv7 and ↵Chris Bieneman2017-09-259-57/+19
| | | | | | | | | | | | | arm64 iOS devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures." This patch has been causing LLDB test failures on ObjC tests. A test log may still be available here: http://lab.llvm.org:8080/green/view/LLDB/job/lldb/1650/ This reverts commit r314038. llvm-svn: 314122
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-229-19/+57
| | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. Both devices pass the testsuite without any errors or failures. I have seen some instability with the armv7 test runs, I may submit additional patches to address this. arm64 looks good. I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 314038
* Revert this patch; I was emailing with Eugene and they have some other ↵Jason Molenda2017-09-219-57/+19
| | | | | | | | | changes going in today and don't want the two changes to confuse the situation with the build bots. I'll commit tomorrow once they're known good. llvm-svn: 313934
* Initial patchset to get the testsuite running against armv7 and arm64 iOS ↵Jason Molenda2017-09-219-19/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | devices. Normal customer devices won't be able to run these devices, we're hoping to get a public facing bot set up at some point. There will be some smaller follow-on patches. The changes to tools/lldb-server are verbose and I'm not thrilled with having to skip all of these tests manually. There are a few places where I'm making the assumption that "armv7", "armv7k", "arm64" means it's an ios device, and I need to review & clean these up with an OS check as well. (Android will show up as "arm" and "aarch64" so by pure luck they shouldn't cause problems, but it's not an assumption I want to rely on). I'll be watching the bots for the rest of today; if any problems are introduced by this patch I'll revert it - if anyone sees a problem with their bot that I don't see, please do the same. I know it's a rather large patch. One change I had to make specifically for iOS devices was that debugserver can't create files. There were several tests that launch the inferior process redirecting its output to a file, then they retrieve the file. They were not trying to test file redirection in these tests, so I rewrote those to write their output to a file directly. llvm-svn: 313932
* remove FreeBSD xfail decorator from TestCppNsImportEd Maste2017-08-101-1/+0
| | | | | | | | | | The Linux xfail decorator was removed in r272326 with the claim that the test "runs reliably on the linux x86 buildbot." It also runs reliably on FreeBSD for me. llvm.org/pr25925 llvm-svn: 310644
* RFix PR33875 by distinguishing between DWO and clang modules.Adrian Prantl2017-07-241-2/+0
| | | | | | | | This reapplies https://reviews.llvm.org/D35740 with a tweak to find the section by name rather than type. Section types don't distinguish between regular sections and their DWO counterparts. llvm-svn: 308905
* Revert "Fix PR33875 by distinguishing between DWO and clang modules"Adrian Prantl2017-07-231-0/+2
| | | | | | This reverts commit r308850. llvm-svn: 308851
* Fix PR33875 by distinguishing between DWO and clang modulesAdrian Prantl2017-07-231-2/+0
| | | | | | | | | | | | | | The DWO handling code can get confused by clang modules which also use skeleton CUs to point to the object file with the full debug info. This patch detects whether an object is a "real" DWO or a clang module and prevents LLDB from interpreting clang modules as DWO. This fixes the regression in TestWithModuleDebugging. http://llvm.org/bugs/show_bug.cgi?id=33875 Differential Revision: https://reviews.llvm.org/D35740 llvm-svn: 308850
* XFail TestWithModuleDebugging on linux (bug 33875)Pavel Labath2017-07-211-0/+2
| | | | llvm-svn: 308732
* Disable TestGoASTContextPavel Labath2017-07-071-0/+1
| | | | | | | it fails with go 1.8 and we don't seem to have a maintainer of that functionality. llvm-svn: 307391
* Updated the NSArray and NSDictionary formatters to support new storage formats.Sean Callanan2017-06-231-4/+0
| | | | | | | | Also un-xfailed a testcase that was affected by this. Thanks to Jason Molenda for the patch. <rdar://problem/32827216> llvm-svn: 306180
* [testsuite] xfailed two tests that depend on NSString conforming to NSCopying.Sean Callanan2017-06-141-0/+4
| | | | | | | | | | | | | NSString is loaded from the DWARF, which doesn't have the concept of protocols. When this is used with the NSMutableDictionary type from Objective-C modules, this produces errors of the form error: cannot initialize a parameter of type 'id<NSCopying> _Nonnull' with an rvalue of type 'NSString *' We're aware of these problems and have an internal bug report filed (<rdar://problem/32777981>) llvm-svn: 305424
* [LLDB][MIPS] Fix TestRegisterVariables.py.Nitesh Jain2017-06-141-1/+1
| | | | | | | | | Clang does not accept regparm attribute on these platforms. Fortunately, the default calling convention passes arguments in registers any way Subscribers: jaydeep, bhushan, lldb-commits, slthakur llvm-svn: 305378
* [TypeSystem] Handle Clang AttributedTypesSean Callanan2017-06-021-10/+121
| | | | | | | | | | | | | | | | | | | When parsing types originating in modules, it is possible to encounter AttributedTypes (such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext methods deal with them; others do not. In particular, one function that did not was GetTypeInfo, causing TestObjCNewSyntax to fail. This fixes that, treating AttributedType as essentially transparent and getting the information for the modified type. In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of different things, all of which can break independently of one another. I broke it apart into smaller tests so that we get more precise failures when something (like this) breaks. Differential Revision: https://reviews.llvm.org/D33812 llvm-svn: 304510
* Added a testcase for local/namespaced name conflicts.Sean Callanan2017-05-313-0/+39
| | | | | | | | | This works on SVN but is a bit fragile on the Swift branch. I'm adding the test to both, so we have this path covered. <rdar://problem/32372372> llvm-svn: 304314
* Make TestConflictingSymbol run on non-darwin targetsPavel Labath2017-05-171-7/+11
| | | | | | | | | | | For remote targets we need to call registerSharedLibrariesWithTarget to make sure they are installed alongside main executable. This also required a small fixup in the the mentioned function as in this case "One" was both a directory name and a library name template. I fixed it to make sure it checks that the string refers to a file before it assumed it was a full library path. llvm-svn: 303248
* [Expression parser] Look up module symbols before hunting globallySean Callanan2017-05-1611-0/+161
| | | | | | | | | | | | | | | | | | | When it resolves symbol-only variables, the expression parser currently looks only in the global module list. It should prefer the current module. I've fixed that behavior by making it search the current module first, and only search globally if it finds nothing. I've also added a test case. After review, I moved the core of the lookup algorithm into SymbolContext for use by other code that needs it. Thanks to Greg Clayton and Pavel Labath for their help. Differential Revision: https://reviews.llvm.org/D33083 llvm-svn: 303223
* [TypeSystem] Fix inspection of Objective-C object typesSean Callanan2017-05-153-0/+94
| | | | | | | | | | | | | | ptr_refs exposed a problem in ClangASTContext's implementation: it uses an accessor to downcast a QualType to an ObjCObjectPointerType, but the accessor is not fully general. getAs() is the safer way to go. I've added a test case that uses ptr_refs in a way that would crash before the fix. <rdar://problem/31363513> llvm-svn: 303110
* xfail TestClassTemplateParameterPack on gcc to mollify ↵Sean Callanan2017-05-111-1/+3
| | | | | | lldb-x86_64-ubuntu-14.04-cmake. llvm-svn: 302850
* [DWARF parser] Produce correct template parameter packsSean Callanan2017-05-116-0/+104
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Templates can end in parameter packs, like this template <class T...> struct MyStruct { /*...*/ }; LLDB does not currently support these parameter packs; it does not emit them into the template argument list at all. This causes problems when you specialize, e.g.: template <> struct MyStruct<int> { /*...*/ }; template <> struct MyStruct<int, int> : MyStruct<int> { /*...*/ }; LLDB generates two template specializations, each with no template arguments, and then when they are imported by the ASTImporter into a parser's AST context we get a single specialization that inherits from itself, causing Clang's record layout mechanism to smash its stack. This patch fixes the problem for classes and adds tests. The tests for functions fail because Clang's ASTImporter can't import them at the moment, so I've xfailed that test. Differential Revision: https://reviews.llvm.org/D33025 llvm-svn: 302833
* Windows fix for TestConflictingDefinition makefilePavel Labath2017-05-031-1/+1
| | | | | | | | | | gnuwin32 rm does not like wildcards that match nothing even if we specify -f (probably because the wildcard expansion happens in-process there). We could use make $(wildcard) here, but it seems safer to explicitly list the files here, just like the normal Makefile.rules does. llvm-svn: 302013
* Fixed a bug where we did not properly use the complete versions of ↵Sean Callanan2017-05-039-0/+134
| | | | | | | | | | Objective-C classes. Also added a test case, thanks to Greg Clayton. <rdar://problem/18913551> llvm-svn: 301993
* Provide a mechanism to do some pre-loading of symbols up front.Jim Ingham2017-04-281-4/+17
| | | | | | | | | | | Loading a shared library can require a large amount of work; rather than do that serially for each library, this patch will allow parallelization of the symbols and debug info name indexes. From scott.smith@purestorage.com https://reviews.llvm.org/D32598 llvm-svn: 301609
* Name the C++ source files for two tests correctly.Sean Callanan2017-04-242-2/+2
| | | | llvm-svn: 301280
* Fixed two bad Makefiles that might be breaking Linux.Sean Callanan2017-04-242-2/+2
| | | | llvm-svn: 301277
* [Expression parser] Return both types and variablesSean Callanan2017-04-247-2/+98
| | | | | | | | | | | | | | | | | | | | | Many times a user wants to access a type when there's a variable of the same name, or a variable when there's a type of the same name. Depending on the precise context, currently the expression parser can fail to resolve one or the other. This is because ClangExpressionDeclMap has logic to limit the amount of information it searches, and that logic sometimes cuts down the search prematurely. This patch removes some of those early exits. In that sense, this patch trades performance (early exit is faster) for correctness. I've also included two new test cases showing examples of this behavior – as well as modifying an existing test case that gets it wrong. llvm-svn: 301273
* [DWARF] Fix lookup in the abstract origins of inlined blocks/functionsSean Callanan2017-04-241-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | LLDB uses clang::DeclContexts for lookups, and variables get put into the DeclContext for their abstract origin. (The abstract origin is a DWARF pointer that indicates the unique definition of inlined code.) When the expression parser is looking for variables, it locates the DeclContext for the current context. This needs to be done carefully, though, e.g.: __attribute__ ((always_inline)) void f(int a) { { int b = a * 2; } } void g() { f(3); } Here, if we're stopped in the inlined copy of f, we have to find the DeclContext corresponding to the definition of f – its abstract origin. Clang doesn't allow multiple functions with the same name and arguments to exist. It also means that any variables we see must be placed in the appropriate DeclContext. [Bug 1]: When stopped in an inline block, the function GetDeclContextDIEContainingDIE for that block doesn't properly construct a DeclContext for the abstract origin for inlined subroutines. That means we get duplicated function DeclContexts, but function arguments only get put in the abstract origin's DeclContext, and as a result when we try to look for them in nested contexts they aren't found. [Bug 2]: When stopped in an inline block, the DWARF (for space reasons) doesn't explicitly point to the abstract origin for that block. This means that the function GetClangDeclContextForDIE returns a different DeclContext for each place the block is inlined. However, any variables defined in the block have abstract origins, so they will only get placed in the DeclContext for their abstract origin. In this fix, I've introduced a test covering both of these issues, and fixed them. Bug 1 could be resolved simply by making sure we look up the abstract origin for inlined functions when looking up their DeclContexts on behalf of nested blocks. For Bug 2, I've implemented an algorithm that makes the DeclContext for a block be the containing DeclContext for the closest entity we would find during lookup that has an abstract origin pointer. That means that in the following situation: { // block 1 int a; { // block 2 int b; } } if we looked up the DeclContext for block 2, we'd find the block containing the abstract origin of b, and lookup would proceed correctly because we'd see b and a. However, in the situation { // block 1 int a; { // block 2 } } since there isn't anything to look up in block 2, we can't determine its abstract origin (and there is no such pointer in the DWARF for blocks). However, we can walk up the parent chain and find a, and its abstract origin lives in the abstract origin of block 1. So we simply say that the DeclContext for block 2 is the same as the DeclContext for block 1, which contains a. Lookups will return the same results. Thanks to Jim Ingham for review and suggestions. Differential revision: https://reviews.llvm.org/D32375 llvm-svn: 301263
* Update two android XFAILSPavel Labath2017-04-241-1/+1
| | | | | | | - XFAIL on TestNoreturnUnwind on all architectures - TestStaticVariables fails with clang-3.8 as well llvm-svn: 301186
* Make TestStaticVariables XFAIL more specificPavel Labath2017-04-201-6/+5
| | | | | | | | The test fails because an older clang did not emit the required debug info (I am not sure when this got added, but clang-3.7 certainly did not work yet). The actual platform has nothing to do with this. llvm-svn: 300834
* Fix TestRegisterVariables for clang/armPavel Labath2017-04-191-2/+11
| | | | | | | | Clang rejects __attribute__((regparm)) when targetting arm. The default calling convention passes arguments in registers anyway, so we can just remove them in this case. llvm-svn: 300670
* TestStaticVariables still fails on Linux.Jim Ingham2017-04-181-0/+2
| | | | llvm-svn: 300519
OpenPOWER on IntegriCloud