<rdar://problem/16006373>

Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do
This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before

llvm-svn: 201455

1 files changed, 4 insertions, 12 deletions

diff --git a/lldb/source/Core/ValueObject.cpp b/lldb/source/Core/ValueObject.cpp
index cf93c86d0b5..10e5ab452f0 100644
--- a/lldb/source/Core/ValueObject.cpp
+++ b/lldb/source/Core/ValueObject.cpp
@@ -1685,12 +1685,8 @@ ValueObject::DumpPrintableRepresentation(Stream& s,
         // area for cases where our desired output is not backed by some other longer-term storage
         StreamString strm;
 
-        bool reset_format = false;
-        if (custom_format != eFormatInvalid && GetFormat() == lldb::eFormatDefault)
-        {
-            reset_format = true;
+        if (custom_format != eFormatInvalid)
             SetFormat(custom_format);
-        }
         
         switch(val_obj_display)
         {
@@ -1745,17 +1741,10 @@ ValueObject::DumpPrintableRepresentation(Stream& s,
             }
         }
         
-        
         if (cstr)
-        {
             s.PutCString(cstr);
-            if (reset_format)
-                SetFormat(lldb::eFormatDefault);
-        }
         else
         {
-            if (reset_format)
-                SetFormat(lldb::eFormatDefault);
             if (m_error.Fail())
             {
                 if (do_dump_error)
@@ -1777,6 +1766,9 @@ ValueObject::DumpPrintableRepresentation(Stream& s,
         // even if we have an error message as output, that's a success
         // from our callers' perspective, so return true
         var_success = true;
+        
+        if (custom_format != eFormatInvalid)
+            SetFormat(eFormatDefault);
     }
     
     return var_success;