dawn added a comment.
Thank you for your review. I was afraid you might not go for it since you
objected to my original frame-based patch for breakpoints, but I had hoped that
by having it in an option you would be OK with it. Our users (with mixed Pascal
and C++ code) really want this so they don't have to remember to specify the
language each time they go up or down the stack and want to view their local
variables. Consider this scenario:
Suppose a user hits a breakpoint in a Pascal function called from C++ and sets
the target language to Pascal so that they can evaluate their locals using the
Pascal FE. Now they go up a frame into C++ and try to see their locals but
can't without resetting the target language (or by always specifying the expr
--language option). Then they run to a BP in a C++ module, same problem.
Does this help explain why having such a default would be so desirable? It is
how all our debuggers and gdb work. I'm curious - how do you get around this
problem in Swift?
================
Comment at: source/Commands/CommandObjectExpression.cpp:303-312
@@ -302,8 +302,12 @@
options.SetDebug(m_command_options.debug);
-
- // If the language was not specified, set it from target's properties
+
+ // If the expression's language was not specified, check the
+ // target's properties to see if a language override was set,
+ // or if the language should match that of the frame.
if (m_command_options.language != eLanguageTypeUnknown)
options.SetLanguage(m_command_options.language);
- else
+ else if (target->GetLanguage() != eLanguageTypeUnknown)
options.SetLanguage(target->GetLanguage());
+ else if (target->GetLanguageFollowsFrame())
+ options.SetLanguage(target->GetLanguageOfSelectedFrame());
----------------
clayborg wrote:
> This should be:
>
> ```
> if (m_command_options.language != eLanguageTypeUnknown)
> options.SetLanguage(m_command_options.language);
> else
> {
> StackFrame *frame = exe_ctx.GetFramePtr();
> if (frame)
> options.SetLanguage(frame-> GetDefaultExpressionLanguage());
> }
> ````
>
>
I would like to have this - see http://reviews.llvm.org/D11102 (you resigned
from that review). Is it OK to add? Or did you want to kill the patch
entirely? Note that setting the language to the frame means that ObjC can't be
evaluated in C++ which Sean is against (see http://reviews.llvm.org/D11173),
and there are tests which expect C++ to be available in ObjC (see
http://reviews.llvm.org/D11102).
Repository:
rL LLVM
http://reviews.llvm.org/D11482
_______________________________________________
lldb-commits mailing list
lldb-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
