[lldb] Extract logic out of GetFunctionDisplayName into a helper function

[charles-zablit]

This patch splits the logic inside SwiftLanguage::GetFunctionDisplayName into reusable helper functions.

• SwiftLanguage::GetFunctionName returns the name of the function as a string.
• SwiftLanguage::GetFunctionDisplayArgs returns the generics and arguments of the function as a string.

This will be needed for #10710

[charles-zablit]

I'm not sure about the changes to the Language::FunctionNameRepresentation::eNameWithNoArgs case. It seems like it should just print the name of the function without its parameters given the name of the enum entry. The patch respects that and will only print the name of the function.

However, this is not what's happening prior to the patch, as the parameters are printed as well.

This does not seem to break any tests in check-lldb but it's probably not tested at all.

[Michael137]

Hmmm why is this new logic needed?

[Michael137]

We didn't previously do this in the NoArgs case right?

[charles-zablit]

I am a bit confused by the original implementation of the NoArgs case: if the frame is foo(a: 1) I would expect the NoArgs case to return foo and nothing else. But in the original implementation, it returns foo(a: Int).

This additional logic is due to me splitting the the logic into 2 helper functions. Say we have foo<T>(a: T). GetFunctionName will return foo and GetFunctionDisplayArgs will return <Int>(a=1).

Hence: no, we didn't previously do this in the NoArgs case, but I think this was a mistake. Since there are no tests for the way backtraces are printed in the Swift plugin, I have no idea how much of a breaking change this is.

[Michael137]

Oh I see. In that case, if eNoArgs was always broken, lets just remove that case entirely? That'll mean less code to change in the other PR (and we won't be breaking any users)

[charles-zablit]

I reverted the changes that were in the eNoArgs case so that the PR does not break existing users. Is that what you meant?

[Michael137]

I meant we should be able to remove the case entirely. If it never worked, it won't break any users 🤷

[charles-zablit]

Is it possible that a client is using this case incorrectly? They would not get any string from this function if that's the case.

[Michael137]

And lets just have 1 helper function that factors out only the stuff in the eNameWithArgs case. Cause that's what you intended to do in #10710 anyway

[Michael137]

Is it possible that a client is using this case incorrectly? They would not get any string from this function if that's the case.

You're saying, if we removed the case, then a client would just not get any string if eFunctionNameNoArgs was used? Yea if that's the case lets just leave it alone for now

[charles-zablit]

And lets just have 1 helper function that factors out only the stuff in the eNameWithArgs case. Cause that's what you intended to do in #10710 anyway

I think it's better to keep them as 2 separate functions. My end goal here is to have a function which takes a function's SymbolContext and returns the arguments parts of the demangled name, i.e (a=1, b=2), without the name.

The initial implementation was tightly coupled with the part that gets the name, meaning you would have to pass in foo(a: Int, b: Int) to GetFunctionDisplayArgs in order to get the desired output.

I think that splitting it into 2 separate components makes it easier to work with.

[Michael137]

@swift-ci test

[charles-zablit]

@swift-ci please test

[Michael137]

This can be removed now

[charles-zablit]

Fixed, thanks

[Michael137]

@swift-ci test