[Lldb-commits] [PATCH] D11482: Add target setting to have the language follow the frame's CU.

[Jim Ingham]

I'm not sure it is that hard.  For the expression parser, we can let folks ask for whatever they want, and then just give them whatever we need to give them.  The mapping is pretty simple, as I said, ask for ObjC, get ObjC++, ask for C++, for now get ObjC++, etc.

I don't know how you guys are doing Pascal expression evaluation?  Do you have a Pascal Clang front-end?  Do you do some kind of Pascal->C and then submit that to clang?  What do you actually need to set here.

Part of the patches you have been submitting have been the breakpoint name chopper's handling of Pascal, but that's independent of the expression parser, and so doesn't so much feature in this discussion.

Jim


> On Jul 28, 2015, at 9:36 PM, Dawn Perchik <dawn+llvm at burble.org> wrote:
> 
> dawn added a comment.
> 
> On Mon, Jul 27, 2015 at 11:24:01AM -0700, Jim Ingham wrote:
> 
>> Just to be clear...  Sean doesn't have a DESIRE to have the expression parser use ObjC++ anytime the language is a C family language.  Rather he MUST right now, because the expression parser uses features of C++ to capture values.  We could switch to using C++ in C/C++ situations, and ObjC++ in others, but there wasn't sufficient motivation to add that.  Sometime when we get some spare cycles we'll try to relax the need for C++, and then we'll truly be able to follow the frame language.  For now, we do "Want C -> get ObjC++", "Want ObjC -> get ObjC++" etc...  But again, that is not a fundamental choice, it is an implementation necessity.
> 
> 
> I see.  This is a major pain for Pascal however, because C++ and ObjC/ObjC++ conflict directly with Pascal, so unless the user specifies the language (via target.language or expr --language), they can't evaluate at all.  So until you guys can find those "spare cycles", we're forced to maintain private patches.
> 
> 
> Repository:
>  rL LLVM
> 
> http://reviews.llvm.org/D11482
> 
> 
>