History log of /external/lldb/test/types/AbstractBase.py
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
6475c42148a8ea1ca86e5db465db7eca742d897d 04-Dec-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12798131>

Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.

This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169189 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
431d839a33e9a274e705f7a268a1c9de2ffc2da2 22-Sep-2012 Jim Ingham <jingham@apple.com> Fix all the test case breakages caused by folks writing tests all over the place that depended explicitly
on the output of "break set". Please don't do this sort of thing!!!!!


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164433 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
4fd809c5b7e71b481f679a52409f76c4a820488d 13-Apr-2012 Johnny Chen <johnny.chen@apple.com> First step to make the test suite runnable for remote platforms.

For the types directory, we were running lldbtest.system() to execute the compiled program
on the test host to collect golden output in order to compare with the output of various
lldb debugger commands as performed later. This won't work for the remote platform
scenario where the architecture of the target and host platforms are different.

Modify the AbstractBase class to use lldb to launch the inferior while specifying the
output file, from which the golden output is collected and grokked. How to bootstrap and
to connect to the remote platform is still being worked at.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154699 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
c21e523a1a7eb74d74d07990c5c12c16982ad1d9 11-Jan-2012 Johnny Chen <johnny.chen@apple.com> Add comment for build_and_run_with_source_atoms_expr() and remove redundant #include from basic_type.cpp.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147895 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
649383a85f4e685e455f0be5997fdd3c508c2627 11-Jan-2012 Johnny Chen <johnny.chen@apple.com> Add documentation for the generic functions build_and_run() and build_and_run_expr() called from
the Test*Types*.py test cases.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147893 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
8563081f48492def461f065b22d8fc502ea6807c 10-Jan-2012 Johnny Chen <johnny.chen@apple.com> Refactor the test/types directory to reduce some stupid reduant code.
Also add test cases to the test suite to exercise displaying of variables captured inside a block (Darwin-only).


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147828 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
99323d8797f5a75dcbf64937422fbc685cf132b6 09-Jan-2012 Johnny Chen <johnny.chen@apple.com> Fix comment.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147789 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
b7e27f4ed399c04362e2f40ba1d800846b819077 24-Jun-2011 Johnny Chen <johnny.chen@apple.com> o lldbtest.py:

Assign the test method name to self.testMethodName. This can be useful for the
test directory (see test/types for a good example) which houses a bunch of executables
compiled from different source files. The default build action is to create a.out as
the binary executable, which can confuse the module cacheing mechanism and result in
the debugger getting a stale image as the target to be debugged, and chaos ensues.

o AbstractBase.py, TestThreadAPI.py:

Use self.testMethodName to our advantage.

o TestLoadUnload.py:

Add expected failure marker to test case test_modules_search_paths().


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133768 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
d062ee862396d29b8c06c60b9e2c38330cf42665 23-Jun-2011 Johnny Chen <johnny.chen@apple.com> Refactorings of the test/types directory to more elegantly express the uniqueness of
executable names given to each test method.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133749 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
2c41e14fd22c79ec2eb0f77dc314e118f04ca232 22-Jun-2011 Johnny Chen <johnny.chen@apple.com> Modify the test cases (there are a bunch of them) under test/types so that they
employ different executable names when creating the target for lldb to debug.
Comparing the log files for the same test case with success/failure results show
that the failed one was setting the breakpoint on some different address than the
succeeded one, leading us to suspect that the file system maybe think it knows better
and caches the wrong executable file (they were all named 'a.out' before) which lldb
subsequently reads from.

Now './dotest.py -v types' passes without specifying the '-w' option.

rdar://problem/9644488
rdar://problem/9649573


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133649 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
d88785b7743c8f4cfa0f5025f5db56f716e6c7b4 21-Jun-2011 Johnny Chen <johnny.chen@apple.com> Add a test file "TestFailures.py" to try to capture test failures which occur when running
with no delay between successive test cases. This one happend to capture a test failure where
the inferior shoud stop at a breakpoint but did not (radar will be filed to capture the log files
as well as the test session files):

[12:40:37] johnny:/Volumes/data/lldb/svn/trunk/test $ DEBUG_LLDB_LOG=/tmp/lldb.log DEBUG_GDB_REMOTE_LOG=/tmp/gdb-remote.log ./dotest.py -v -p TestFailures.py
LLDB-63
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 133529
Node Kind: directory
Schedule: normal
Last Changed Author: jmolenda
Last Changed Rev: 133500
Last Changed Date: 2011-06-20 19:57:15 -0700 (Mon, 20 Jun 2011)



Session logs for test failures/errors/unexpected successes will go into directory '2011-06-21-12_40_42'
Command invoked: python ./dotest.py -v -p TestFailures.py
----------------------------------------------------------------------
Collected 10 tests

1: test_char_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
2: test_char_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that char-type variables are displayed correctly. ... ok
3: test_int_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
4: test_int_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that int-type variables are displayed correctly. ... ok
5: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... FAIL
6: test_long_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly. ... ok
7: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... TestFailures.DebugIntegerTypesFailures.test_long_type_with_dsym
FAIL
8: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly. ... FAIL
9: test_short_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok
10: test_short_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that short-type variables are displayed correctly. ... ok

======================================================================
FAIL: test_long_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that 'long long'-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 102, in test_long_long_type_with_dsym
self.long_long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 129, in long_long_type
self.generic_type_tester(set(['long long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

======================================================================
FAIL: test_long_type_with_dsym (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 87, in test_long_type_with_dsym
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

======================================================================
FAIL: test_long_type_with_dwarf (TestFailures.DebugIntegerTypesFailures)
Test that long-type variables are displayed correctly.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 94, in test_long_type_with_dwarf
self.long_type()
File "/Volumes/data/lldb/svn/trunk/test/types/TestFailures.py", line 125, in long_type
self.generic_type_tester(set(['long']))
File "/Volumes/data/lldb/svn/trunk/test/types/AbstractBase.py", line 67, in generic_type_tester
"stop reason = breakpoint"])
File "/Volumes/data/lldb/svn/trunk/test/lldbtest.py", line 863, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : Process should be stopped due to breakpoint

----------------------------------------------------------------------
Ran 10 tests in 5.617s

FAILED (failures=3)
Session logs for test failures/errors/unexpected successes can be found in directory '2011-06-21-12_40_42'
[12:40:47] johnny:/Volumes/data/lldb/svn/trunk/test $


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133537 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
9a9fcf668980788b50322dfd28287ceb81486918 21-Jun-2011 Johnny Chen <johnny.chen@apple.com> For now, insert some delays between succesive test cases in the test/types directory
if not already specified by the test driver (via ./dotest -w). Remove the AbstractBase.setUp()
method definition when/if we find out the cause of the failures if no delays are inserted
between these test cases.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
c9aabf097245642531d74410ff1371a97991af64 21-Jun-2011 Johnny Chen <johnny.chen@apple.com> Simplify the the generic AbstractBase.py test base for testing variable types.
We still have the the issue where running:

./dotest.py -v types

we have test failures where the inferior either runs to exited with status 0 or
the inferior stops but not because of breakpoint (for example):

runCmd: process status
output: Process 90060 stopped
* thread #1: tid = 0x2d03, 0x000000010000e2ca, stop reason = EXC_BAD_ACCESS (code=2, address=0x10000e2ca)
frame #0: 0x000000010000e2ca

There are two cases where the inferior stops for the breakpoint (good), but the expression parser
prints out the wrong information. The two failures are:

Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dsym.log
Failure-TestFloatTypesExpr.FloatTypesExprTestCase.test_double_type_with_dwarf.log

I'll file a radar on the two expression parser misbehave, while continue investigating why the
inferior stops for the wrong reason or does not stop at all.

For now, you'll need to do:

./dotest.py -v -w types


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133488 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
e6bd142d9fa7ed149bd37efd8a75637375f165b7 20-Jun-2011 Jim Ingham <jingham@apple.com> Use the dyld_mode, image_infos & image_infos_count passed into the shared library notification function
to update libraries rather than reading the whole all_imaage_infos structure every time we get notified.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133448 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
10de7d1db3ec782ea2ccda1f39c0a40b9c301594 04-May-2011 Jim Ingham <jingham@apple.com> Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay).
Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target,
and dynamic with running target.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
0bfa859ea49d27efd89d5f152b8371b39919d92d 23-Mar-2011 Johnny Chen <johnny.chen@apple.com> Turns out that the test failure wrt:

rdar://problem/9173060 lldb hangs while running unique-types

disappears if running with clang version >= 3. Modify the TestUniqueTypes.py
to detect if we are running with clang version < 3 and, if true, skip the test.

Update the lldbtest.system() function to return a tuple of (stdoutdata, stderrdata)
since we need the stderr data from "clang -v" command. Modify existing clients of
lldbtest.system() to now use, for example:

# First, capture the golden output emitted by the oracle, i.e., the
# series of printf statements.
- go = system("./a.out", sender=self)
+ go = system("./a.out", sender=self)[0]
# This golden list contains a list of (variable, value) pairs extracted
# from the golden output.
gl = []

And add two utility functions to lldbutil.py.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128162 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
21c7c21234079dbd52ed25e9a121212663ba242d 02-Dec-2010 Johnny Chen <johnny.chen@apple.com> On second thought, inserting a delay of 1.0 second slows down the test suite
for the types directory quite a bit and masking out potential problems. Enable
the delay via an environment variable, instead.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@120719 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
118d742036e0a8b04c5efb65a39fa6bbf461aa2f 02-Dec-2010 Johnny Chen <johnny.chen@apple.com> GenericTester.generic_type_expr_tester():

Don't overwhelm the expression mechanism. Previously, there was no delay
between successive invocations of 'expression' command. The test suite
run has experienced 'Resume timed out' or similar error messages. Now we
currently add a sleep of 1.0 second before issuing the next 'expression'
command.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@120626 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
66a03531e5199f13482e46777f350312a2b950c1 02-Nov-2010 Johnny Chen <johnny.chen@apple.com> Clean up the test case by removing the filtering code related to fixed radars.
Also modify the:

self.runCmd("expr %s" % var)

to be:

self.runCmd("expression %s" % var)

since 'expr' is an alias of expression. And fix the assert message to be either
'frame variable -t %s' or 'expression %s'.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118085 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
51287a1b5f1524f2e6b14254b41a80908b060668 02-Nov-2010 Johnny Chen <johnny.chen@apple.com> The remaining reference-related variable display failures have been fixed.
Comment out the filtering code. The next check in will clean up the test case
by wiping off the filtering related logic.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118081 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
19edbc5223c7ace86c983c3cc6bd9e610cd329c8 02-Nov-2010 Johnny Chen <johnny.chen@apple.com> Remove the reference-related variable displays that now pass from the 'notnow' set.
The failures that remain are:

# rdar://problem/8620735 test/types: frame variable -t a_class_ref.m_b fails
# The reference type related failures that remain are:
notnow = set(['a_class_ref.m_b',
'a_struct_ref.b',
'a_union_nonzero_ref.u.a'])


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118021 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
1b7d629b11af2ac7a20d899ee1404ef7cd5d4268 16-Oct-2010 Johnny Chen <johnny.chen@apple.com> Some re-achitecturing of the plugins interface. The caller is now required to
pass in a 'sender' arg to the buildDefault(), buildDsym(), buildDwarf(), and
cleanup() functions. The sender arg will be the test instance itself (i.e.,
an instance of TestBase). This is so that the relevant command execution can be
recorded in the TestBase.session object if sender is available.

The lldbtest.system() command has been modified to pop the 'sender' arg out of
the keyword arguments dictionary and use it as the test instance to facilitate
seesion recordings. An example is in test/types/AbstractBase.py:

def generic_type_tester(self, atoms, quotedDisplay=False):
"""Test that variables with basic types are displayed correctly."""

# First, capture the golden output emitted by the oracle, i.e., the
# series of printf statements.
go = system("./a.out", sender=self)

There are cases when sender is None. This is the case when the @classmethod is
involved in the use of these APIs. When this happens, there is no recording
into a session object, but printing on the sys.stderr is still honored if the
trace flag is ON.

An example is in test/settings/TestSettings.py:

@classmethod
def classCleanup(cls):
system(["/bin/sh", "-c", "rm -f output.txt"])
system(["/bin/sh", "-c", "rm -f stdout.txt"])



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116648 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
34f99221dcb055d3a35b6174e0d818fdb73da878 13-Oct-2010 Johnny Chen <johnny.chen@apple.com> Fix these comments and the commented out code about 'frame variable -t', too.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116420 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
c401e37b99cca3482bacb7bc98cc09d69a1cd2ac 13-Oct-2010 Johnny Chen <johnny.chen@apple.com> Apply (query-replace "frame variable" "frame variable -t") and fix a comment about 'expr var',
not 'frame variable var'.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116419 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
6e81fa35eae0a3c6ca8aee19c4bb2f231b6ab912 06-Oct-2010 Johnny Chen <johnny.chen@apple.com> Change the regular expression used to grok the data type associated the output of
expression parser in light of the recent check ins.

Example:
runCmd: expr a
output: (double) $0 = 1100.12


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115821 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
cdf15137e61a3302c038ee92211cb6ec77a5b04e 29-Sep-2010 Johnny Chen <johnny.chen@apple.com> Simple refactoring.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115075 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
5fed90a7c7f5b496bc6e7453b7aaec2ff8e6399d 29-Sep-2010 Johnny Chen <johnny.chen@apple.com> Wrapped the regexp grokking of data type within a try:expect: instead of letting
the Python runtime take over in case there isn't a match.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115073 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
5a3a3d968116e73a80b917a8d9c54ccdd92e2a8c 29-Sep-2010 Johnny Chen <johnny.chen@apple.com> Added an example 'frame variable' output to demonstrate how the generic_type_tester
groks the data type of the variable.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115070 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
bbeb60e635279b68aa70c512cac5127d4c1f1348 29-Sep-2010 Johnny Chen <johnny.chen@apple.com> Turn on generic type tester for expression parser; preparing to file bugs.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115063 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
b6c15f5bcdf67d4912a29623f1a24fb0316de69f 28-Sep-2010 Johnny Chen <johnny.chen@apple.com> Added TestIntegerTypesExpr.py and TestFloatTypesExpr.py which exercise 'expr'
command on the various basic types, similar to TestIntegerTypes.py and
TestFloatTypes.py, which exercise 'frame variable' on the various basic types.

Right now, they don't employ the self.expect() facility to compare against the
golden output. They just invoke the self.runCmd() method to run the 'expr'
command. Decorated the two classes with @unittest2.skip decorators for the time
being.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114987 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
560a77c79a0909c49398155f01a1e75add622632 28-Sep-2010 Johnny Chen <johnny.chen@apple.com> Trivial assert message modification.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114927 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py
51a9e00e10d29ba01af7bc2d5efbcf31ec1f76a4 28-Sep-2010 Johnny Chen <johnny.chen@apple.com> Use a better name for the abstract base class which contains the generic_type_tester()
method. Renamed it to be AbstractBase.py, which contains the GenericTester class that
both IntegerTypesTestCase and FloatTypesTestCase inherit from.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@114926 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/test/types/AbstractBase.py