[Lldb-commits] [PATCH] D11119: Parse breakpoint expressions using the language of the frame's CU.

[Dawn Perchik]

dawn added a comment.

Many thanks for taking the time to review!  This new language support is painful... I'm grateful you're willing to work with me on it!!

> I would rather see smarts go into Module::PrepareForFunctionNameLookup() and teach it to pull apart names like "ns.foo" and do the right thing. If a string comes into Module::PrepareForFunctionNameLookup() that contains <indentifier>.<indentifier> repeated as many times as needed (<indentifier>.<indentifier>.<indentifier>.<indentifier>) then we should correctly pull those apart and search for "foo" and then match against "ns.foo" (just like Module::PrepareForFunctionNameLookup() takes "ns::foo" and looks up "foo" and then matches agains "ns::foo").  I don't think we need a language indicator to tell us, we should be able to just break it up without that hint.


Currently this "pulling apart" happens via CPPLanguageRuntime.  Do you want a version of
CPPLanguageRuntime that handle Pascals as well; a LanguageRuntime::ExtractContextAndIdentifier that is a superset and iterate through that?  The problem is that the type mask can come in as eFunctionNameTypeMethod or eFunctionNameTypeBase.  What C++ does with this (how it would split it apart) is different from how Pascal would split it.  How would you workaround that?

> We could provide a language hint to Module::PrepareForFunctionNameLookup() if we want to and then have the user specify "--language pascal" when doing the "breakpoint set --name ns.foo --language pascal", but we shouldn't be using any frame's compile unit language to do so.


Yes, I plan to add options like this, but wanted to use the frame's CU as the default, just as gdb does.  It's a pain for a Pascal user to always have to specify "--language pascal" every time they want to set a breakpoint or evaluate a string.  Agreed - using the frame's CU isn't perfect either, but it's the option gdb adopted, so has precedence and years of acceptance.

But I hear you, and will revise this patch to work off an option instead.

I had looked at adding language options settings... getting those options down to the code that needs to check them will change quite a few APIs.  I also wasn't sure how best to specify the language - should it be a global setting that breakpoints and evaluation both use, or should each command have a "--language" option?


Repository:
  rL LLVM

http://reviews.llvm.org/D11119