[Lldb-commits] [lldb] r327356 - [ExpressionParser] Fix crash when evaluating invalid expresssions.

[Davide Italiano via lldb-commits]

On Mon, Mar 12, 2018 at 7:27 PM, Jason Molenda via lldb-commits
<lldb-commits at lists.llvm.org> wrote:
> FWIW, we'll definitely get pushback about
>
>> Now you can't do in lldb anymore
>> (lldb) call _Zsomethingsomething(1,2,3)
>
>
> There are clever users of lldb, often working at assembly language level without any symbolic information, who are able to correctly call a C++ mangled function by hand.  It's not something I'd want to do personally, but I'd be mad at my debugger if it gave me an error message when I told it what to do.
>
>

I understand your point. We had several discussions about this and I
was really reluctant to push this change to begin with.
I thought about alternatives and basically I ended up realizing that
maintaining the invariants that the AST wants Is crazytown.
You don't need to squint too hard to see that basically nobody using
clang does this.
All the clang tools prefer to insert text in a source file and reparse
it because modifying the AST in place is hard.
It's funny that they do that because the changes they make are
generally fairly localized, but nobody really understands what Sema
really wants (note, the invariants are hardcoded in the Sema path).
Injecting a generic decl in the context and crossing finger is not
really great IMHO. It causes crashes, which, from what I understand in
the lldb world are much worse than not being able to display
informations (from what I can see the mantra of lldb is "the debugger
should never crash").

So, yes, this patch is in some way picking one of two poisons. If we
want to take a look at this again (i.e. we consider it important
enough), then the interaction between debugger and compiler needs to
be rethought to inject something less terrible than a generic decl.
This is, needless to say, fairly hard because in this case you're
getting the symbols from a Mach-O object file, so all the state you
have is a mangled symbol name, which doesn't contain enough
information to reconstruct the whole context. In swift we can do
better because we have a fully-fledged type reconstruction mechanism
(swift::ide::GetTypeFromMangledSymbolName()), and even there, we
experienced a fair amount of pain because the path still has issues
that need to be shaken.

tl;dr if somebody wants to rewrite this, I'll be very happy to support
this , but I don't see a real reason to keep the feature in an
half-baked state.

Best,

--
Davide