-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[lldb] Fix a regression in SBValue::GetObjectDescription() #117242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@llvm/pr-subscribers-lldb Author: Adrian Prantl (adrian-prantl) ChangesThe old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea. rdar://133956263 Full diff: https://github.com/llvm/llvm-project/pull/117242.diff 2 Files Affected:
diff --git a/lldb/source/API/SBValue.cpp b/lldb/source/API/SBValue.cpp
index b35c82250d6ba1..a707b9aa7589c7 100644
--- a/lldb/source/API/SBValue.cpp
+++ b/lldb/source/API/SBValue.cpp
@@ -380,8 +380,10 @@ const char *SBValue::GetObjectDescription() {
return nullptr;
llvm::Expected<std::string> str = value_sp->GetObjectDescription();
- if (!str)
- return ConstString("error: " + toString(str.takeError())).AsCString();
+ if (!str) {
+ llvm::consumeError(str.takeError());
+ return nullptr;
+ }
return ConstString(*str).AsCString();
}
diff --git a/lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py b/lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
index b9b5bffb87e817..a68e921ef02dba 100644
--- a/lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
+++ b/lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
@@ -194,7 +194,12 @@ def test_error_type(self):
frame = thread.GetFrameAtIndex(0)
value = frame.EvaluateExpression('#error("I am error.")')
error = value.GetError()
- self.assertEqual(error.GetType(), lldb.eErrorTypeExpression)
+ self.assertEqual(error.GetType(), lldb.eErrorTypeExpression);
+ value = frame.FindVariable('f')
+ self.assertTrue(value.IsValid());
+ desc = value.GetObjectDescription()
+ self.assertEqual(desc, None);
+
def test_command_expr_sbdata(self):
"""Test the structured diagnostics data"""
|
✅ With the latest revision this PR passed the Python code formatter. |
e4a6563
to
dc8c387
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, that isn't a great API. But at least this way you can tell whether to use the object description w/o having to detect an error string in the output.
At some point we should add a better API. I think just an overload that takes an SBError would be fine. But that's not necessary for this patch.
The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea. rdar://133956263
dc8c387
to
0ee1d8b
Compare
The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea. rdar://133956263 (cherry picked from commit 7553fb1) Conflicts: lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
[lldb] Fix a regression in SBValue::GetObjectDescription() (llvm#117242)
The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea. rdar://133956263 (cherry picked from commit 7553fb1) Conflicts: lldb/test/API/commands/expression/diagnostics/TestExprDiagnostics.py
The old behavior was to return a null string in the error case,when refactoring the error handling I thought it would be a good idea to print the error in the description, but that breaks clients that try to print a description first and then do something else in the error case. The API is not great but it's clear that in-band errors are also not a good idea.
rdar://133956263