This is an archive of the discontinued LLVM Phabricator instance.

[lldb][CPlusPlus] Introduce CPlusPlusLanguage::MethodName::GetReturnType
ClosedPublic

Authored by Michael137 on Oct 28 2022, 2:59 AM.

Details

Summary

This patch adds a way to extract the return type out
of the CPlusPlusNameParser. This will be useful
for cases where we want a function's basename *and* the
return type but not the function arguments; this is
currently not possible (the parser either gives us the
full name or just the basename). Since the parser knows
how to handle return types already we should just expose
this to users that need it.

Testing

  • Added unit-tests

Diff Detail

Event Timeline

Michael137 created this revision.Oct 28 2022, 2:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2022, 2:59 AM
Michael137 requested review of this revision.Oct 28 2022, 2:59 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2022, 2:59 AM
  • Fix unit-tests
  • Handle function pointer types
Michael137 retitled this revision from [lldb][CPlusPlus] Introuce CPlusPlusLanguage::MethodName::GetReturnType to [lldb][CPlusPlus] Introduce CPlusPlusLanguage::MethodName::GetReturnType.Oct 28 2022, 3:25 AM

The return type handling for function pointers is not correct. If it's hard to do, then maybe we could skip it (i suspect the original code didn't handle that either), but I have a feeling it might not be that hard, given that we're already able correctly extract the innermost argument types.

lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
85–88

I believe the return type here should be something like string (*)(float) (a pointer to a function that takes a float and returns a string).

The return type handling for function pointers is not correct. If it's hard to do, then maybe we could skip it (i suspect the original code didn't handle that either), but I have a feeling it might not be that hard, given that we're already able correctly extract the innermost argument types.

Ah good catch, yes the original code just seems to skip the first typename (which need not be the actual return type if we're returning function pointers) since it only cares about the base name and arguments. Will see how easy this is to handle

Michael137 added a comment.EditedOct 28 2022, 9:48 AM

The return type handling for function pointers is not correct. If it's hard to do, then maybe we could skip it (i suspect the original code didn't handle that either), but I have a feeling it might not be that hard, given that we're already able correctly extract the innermost argument types.

The slightly unfortunate bit is that if we wanted to collect all but the inner function name into m_return_type we'd have to allocate a new string and do some concatenation (or create some sort of struct ReturnType { llvm::StringRef LHS, RHS }). Not too difficult to implement AFAICT but not sure we need to support this at the moment. Functions that have a function return type encoded in the mangled name currently don't format correctly, so not supporting it wouldn't regress that. Wdyt?

Either way a great test-case to add

hawkinsw added inline comments.
lldb/unittests/Language/CPlusPlus/CPlusPlusLanguageTest.cpp
85–88

I read this "nice" function pointer declaration as:

declare f as a function that takes a vector<int> by r-value reference that, in turn, returns a pointer to a function taking a float by value that returns a string.

Upon writing that out, I realize that I am basically saying the same thing as @labath. Sorry!

  • Don't handle function-pointer return types for now
  • Add more documentation
labath accepted this revision.Oct 31 2022, 4:25 AM

The return type handling for function pointers is not correct. If it's hard to do, then maybe we could skip it (i suspect the original code didn't handle that either), but I have a feeling it might not be that hard, given that we're already able correctly extract the innermost argument types.

The slightly unfortunate bit is that if we wanted to collect all but the inner function name into m_return_type we'd have to allocate a new string and do some concatenation (or create some sort of struct ReturnType { llvm::StringRef LHS, RHS }). Not too difficult to implement AFAICT but not sure we need to support this at the moment. Functions that have a function return type encoded in the mangled name currently don't format correctly, so not supporting it wouldn't regress that. Wdyt?

Sounds good. Ship it.

This revision is now accepted and ready to land.Oct 31 2022, 4:25 AM