4 Commits

Author SHA1 Message Date
Dawn Perchik
009d110de4 Set the default language to use when evaluating to that of the frame's CU.
* Use the frame's context (instead of just the target's) when evaluating,
  so that the language of the frame's CU can be used to select the
  compiler and/or compiler options to use when parsing the expression.
  This allows for modules built with mixed languages to be parsed in
  the context of their frame. 
* Add all C and C++ language variants when determining the language options
  to set.
* Enable C++ language options when language is C or ObjC as a workaround since
  the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
  requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
  for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
  to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.

Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102

llvm-svn: 246829
2015-09-04 01:02:30 +00:00
Sean Callanan
05834cd2ad Reversed r238363, because the message is inconsistent
with all the other assertion messages.

llvm-svn: 241212
2015-07-01 23:56:30 +00:00
Siva Chandra
3154aa23f3 [TestBase.runCmd] Better error message when runCmd fails.
Summary:
Before:
    AssertionError: False is not True : Process is launched successfully

After:
    AssertionError: False is not True : Command 'run a.out' failed.
    >>> error: invalid target, create a target using the 'target create' command
    >>> Process could not be launched successfully

Reviewers: clayborg

Reviewed By: clayborg

Subscribers: lldb-commits, vharron

Differential Revision: http://reviews.llvm.org/D9948

llvm-svn: 238363
2015-05-27 22:27:41 +00:00
Enrico Granata
bb642e5456 Constant result ValueObjects are - well - constant
And they also do not have a thread/frame attached to them

That makes dynamic and synthetic values attached to them impossible to update - which, among other things, makes it impossible to properly display persistent variables of types that could have such dynamic/persistent values

Fix this by making it so that a ValueObject can control its constantness (hint: dynamic and synthetic values cannot be constant) and whether it wants to let itself be updated when an invalid thread is around

llvm-svn: 237504
2015-05-16 01:27:00 +00:00