[Lldb-commits] [PATCH] D11790: Fix ObjC++ types Class and id being defined in C and C++ expressions.

[Dawn Perchik via lldb-commits]

dawn added a comment.

Hi Sean,

In http://reviews.llvm.org/D11790#221730, @spyffe wrote:

> Ooh, I'm reading the patch at the beginning of ClangUserExpression::Evaluate again and it does look like this patch sets language based on the language of the containing frame, and that affects what language the expression is parsed in.


Yep - and I agree that this is a good thing.

> I don't think it's appropriate to force the expression parser out of Objective-C or C++ mode in non-ObjC frames ...


But the parsing of ObjC conflicts with other languages.  This is a real problem.

> For the same reason I think the idea of a target-level language isn't the right approach.


I agree here.

> Rather, I think there should be a setting that says "force all expressions to this language by default" that the user can set if they're debugging a process that prefers a particular language.


We have such a setting with target.language.

> By default, this setting would be Objective-C++


I disagree here - the default is (and should be) unknown.

In http://reviews.llvm.org/D11790#221770, @paulherman wrote:

> The idea is that, as I user, I do not expect the identifiers "Class" and "id" to not be available - I don't think I've seen a warning or notice about that when evaluating expressions.
>
> I believe that setting the language based on the current frame is a good guess. I think evaluating something in the language of the current frame is more common than evaluating something that is in ObjC++ and the current frame is C++.


I'm totally with Paul on this, and we've discussed this same issue in http://reviews.llvm.org/D11482, http://reviews.llvm.org/D11173 and http://reviews.llvm.org/D11102.  It was Jim's belief that you would be in favor of using the frame too, but here it sounds like you *do* want to always be able to eval ObjC, which contradicts Jim and Greg.  I believe the approach I took in http://reviews.llvm.org/D11102 is exactly what was requested from Greg and Jim.  If you disagree, please talk to them, because Paul and I are stuck between two conflicting desires here, and we can't move forward.  Note that my patch at http://reviews.llvm.org/D11102 still awaits your review.

Thanks,
-Dawn


http://reviews.llvm.org/D11790