summaryrefslogtreecommitdiffstats
path: root/lldb/packages/Python/lldbsuite/test/lang
Commit message (Collapse)AuthorAgeFilesLines
* 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
* This test is succeeding on macOS with clang.Jim Ingham2017-04-181-6/+1
| | | | llvm-svn: 300517
* Fix TestCppIncompleteTypes for android/clangPavel Labath2017-04-121-2/+2
| | | | | | | LDFLAGS contains some .a files. If it is specified before the relevant object files, undefined symbol errors occur. llvm-svn: 300048
* FindTypes should find "struct TypeName" as well as "TypeName".Jim Ingham2017-03-213-0/+95
| | | | | | | | | | This fixes a bug introduced by r291559. The Module's FindType was passing the original name not the basename in the case where it didn't find any separators. I also added a testcase for this. <rdar://problem/31159173> llvm-svn: 298331
* Fix TestRegisterVariables for linux arm/arm64 gcc ver > 5Omair Javaid2017-01-131-1/+1
| | | | | | | | | We are going to turn off buffer overflow introduced by gcc by turning off FORTIFY_SOURCE. Differential revision: https://reviews.llvm.org/D28666 llvm-svn: 291949
* XFAIL TestRegisterVariables on gcc-4.8-x86_64Pavel Labath2017-01-101-0/+2
| | | | | | | I have previously enabled this test for this configuration. However, it turns out it only passes for gcc-4.9. llvm-svn: 291563
* Fix i386 being able to show member variables correctly by not returning ↵Greg Clayton2016-12-092-4/+5
| | | | | | | | | | empty objective C types from the runtime. We don't parse ObjC v1 types from the runtime metadata like we do for ObjC v2, but doing so by creating empty types was ruining the i386 v1 debugging experience. <rdar://problem/24093343> llvm-svn: 289233
* Handle UTF-16 and UTF-32 constant CFStringsSean Callanan2016-12-012-0/+11
| | | | | | | | | | | | | | | We have a longstanding issue where the expression parser does not handle wide CFStrings (e.g., @"凸凹") correctly, producing the useless error message Internal error [IRForTarget]: An Objective-C constant string's string initializer is not an array error: warning: expression result unused error: The expression could not be prepared to run in the target This is just a side effect of the fact that we don't handle wide string constants when converting these to CFStringCreateWithBytes. That function takes the string's encoding as an argument, so I made it work and added a testcase. https://reviews.llvm.org/D27291 <rdar://problem/13190557> llvm-svn: 288386
* Enable TestBitfields on linux with clangPavel Labath2016-11-241-7/+0
| | | | | | The test has been passing for a while now. llvm-svn: 287884
* Enable TestRegisterVariables for some configurationsPavel Labath2016-11-241-5/+2
| | | | | | It consistently passes for linux-clang-i386, and linux-gcc-x86_64. llvm-svn: 287883
* Mark xfail TestNamespaceDefinitions for arm/aarch64 targetsOmair Javaid2016-11-111-0/+3
| | | | | | | | Fails with all versions of arm/aarch64 gcc available on ubuntu 16.04/14.04. Passes with Linaro GCC version >= 4.8 but fails with >= 5.0. But There are other regressions when we use Linaro GCC. llvm-svn: 286574
* Un-XFail test on Windows. Has been in "unexpected success" mode for a while.Adrian McCarthy2016-11-101-2/+0
| | | | llvm-svn: 286476
* Fix expectation in TestStaticVariables.py after rL286302Tamas Berghammer2016-11-091-1/+1
| | | | | | | | The debug info emitted by clang for static variables improved by rL286302 and it exposed an incorrect test expactation because now LLDB able to displays more data 9thanks to better debug info) then before. llvm-svn: 286360
* Fix an issue where frame variable -s <varname> would not show the scope even ↵Enrico Granata2016-10-261-1/+1
| | | | | | | | though the user asked for it Part of rdar://28434047 llvm-svn: 285226
* remove xfail from TestObjCNewSyntax.py test_expr_gmodules()Todd Fiala2016-10-241-4/+0
| | | | | | | Fixes: rdar://27792848 llvm-svn: 285032
* Added a decorator for the macOS version and switched over testcases that ↵Sean Callanan2016-10-206-13/+6
| | | | | | used platform.release llvm-svn: 284674
* Remove a debug print statement.Jim Ingham2016-10-181-1/+0
| | | | llvm-svn: 284448
* More testsuite xfail markings cleanup.Jim Ingham2016-10-182-3/+2
| | | | llvm-svn: 284446
* This test is no longer failing for gmodules.Jim Ingham2016-10-151-4/+0
| | | | llvm-svn: 284296
* This test passes on i386 now.Jim Ingham2016-10-141-4/+0
| | | | llvm-svn: 284183
* This test is passing on i386 now.Jim Ingham2016-10-141-2/+0
| | | | llvm-svn: 284182
* This test now passes.Jim Ingham2016-10-121-2/+0
| | | | llvm-svn: 283959
* This was skipped due to a clang PR that has been fixed.Jim Ingham2016-10-111-1/+0
| | | | llvm-svn: 283957
* Added a radar on our end for this test's failure.Jim Ingham2016-10-111-1/+1
| | | | llvm-svn: 283956
* Fixing the bug number for darwin on this failure.Jim Ingham2016-10-111-1/+3
| | | | llvm-svn: 283843
* The PR that caused this test ot fail was fixed in July, removing the XFAIL.Jim Ingham2016-10-071-1/+0
| | | | llvm-svn: 283578
* Fixup the xfail situation on Windows.Zachary Turner2016-10-059-4/+7
| | | | | | Xfails added and/or removed to reflect the current state of Windows. llvm-svn: 283380
* The collision of class C and libsystem_c.dylib:C is a failureJim Ingham2016-10-051-2/+17
| | | | | | | worth preserving, but not essential to the purpose of this test so I broke it into a separate test. llvm-svn: 283289
* This test is failing because there's a global symbol "C" in libsystem_c.dylib,Jim Ingham2016-10-051-1/+1
| | | | | | and that is defeating the lookup of the "struct C" here. Adding the bug for that. llvm-svn: 283287
* Skip TestRuntimeIvars on i386; the Objective-C V1 runtime doesn't list ivars.Sean Callanan2016-09-301-1/+1
| | | | llvm-svn: 282869
* Add some logging when trace is on. We're getting a bot failure on i386 that ↵Jim Ingham2016-09-291-8/+15
| | | | | | | | doesn't I can't reproduce locally. Hopefully this will help us catch the reason. llvm-svn: 282810
* Don't expect new-style Objective-C literals to work on i386 with the V1 runtime.Sean Callanan2016-09-291-0/+1
| | | | llvm-svn: 282794
* Fixed TestObjCMethods2/i386 by separating out the portions that require ObjC V2.Sean Callanan2016-09-291-13/+17
| | | | llvm-svn: 282787
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-06118-2305/+4110
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Don't crash when trying to capture persistent variables in a block.Sean Callanan2016-08-261-1/+3
| | | | | | | | | Reports an error instead. We can fix this later to make persistent variables work, but right now we hit an LLVM assertion if we get this wrong. <rdar://problem/27770298> llvm-svn: 279850
* Make all the Function implementations different so the compiler won't share ↵Jim Ingham2016-08-262-56/+54
| | | | | | | | | | | | | | them. Clang on ARM64 was making the three Function methods with identical bodies have one implementation that was shared. That threw off the count of breakpoints, since we don't count as separate locations three functions with the same address. I also cleaned up the test case while I was at it. <rdar://problem/27001915> llvm-svn: 279800
* Fix expression evaluation with operator newPavel Labath2016-08-152-4/+54
| | | | | | | | | | | | | | | | Summary: referencing a user-defined operator new was triggering an assert in clang because we were registering the function name as string "operator new", instead of using the special operator enum, which clang has for this purpose. Method operators already had code to handle this, and now I extend this to cover free standing operator functions as well. Test included. Reviewers: spyffe Subscribers: sivachandra, paulherman, lldb-commits Differential Revision: http://reviews.llvm.org/D17856 llvm-svn: 278670
* XFAIL TestNamespaceDefinitions on gcc-4.8 and belowPavel Labath2016-08-121-0/+2
| | | | llvm-svn: 278491
* xfailed TestObjCNewSyntax.py on macOS for gmodulesTodd Fiala2016-08-101-0/+1
| | | | | | | Tracked by: rdar://27792848 llvm-svn: 278289
* Undid LLVM macro usage in test suite test subject files.Todd Fiala2016-08-102-11/+11
| | | | llvm-svn: 278197
OpenPOWER on IntegriCloud