[lldb] Support breakpoints on specific property accessor blocks

[kastiglione]

Allows breakpoints to be set on computed properties, as well as other property accessor blocks including setters, and observers (willSet, didSet).

This change allows property accessor blocks to be set using the suffix generated for these by the compiler. They are:

• .get
• .set
• .willset
• .didset

In particular, this change allows the following command to work: b computed_prop.get. This will create a breakpoint on a computed property's getter – which is the motivation of this change. Currently, there's no way to set a breakpoint by name on computed properties.

Note that these suffixes are emitted by the compiler into debug info. Ex:

% dwarfdump main.dSYM | grep computed_prop
                    DW_AT_linkage_name	("$s4main1SV13computed_propSbvg")
                    DW_AT_name	("computed_prop.get")

rdar://125740294

[kastiglione]

TODO

• Test core functionality
• Test false positives

[jimingham]

Saying that the getter & setter names are variants of the property name makes sense.

Is it worth thinking of a way to specify "only setters" or "only getters"? You can always disable the extra locations after the fact, but that might get tedious.

This needs some tests, first that show it works for the property access variants. It would also be nice to test that this doesn't cause unintended hits against classes that just happen to have a method with one of these names.

[kastiglione]

Is it worth thinking of a way to specify "only setters" or "only getters"?

I don't understand. With this change, property breakpoints must explicitly indicate which accessor the breakpoint should be set on (.get, .set, etc).

This needs some tests, first that show it works for the property access variants.

done ✅

It would also be nice to test that this doesn't cause unintended hits against classes that just happen to have a method with one of these names.

I'm also not sure what you mean. Could you illustrate an example of an unintended match? thanks

[kastiglione]

@swift-ci test

[kastiglione]

It would also be nice to test that this doesn't cause unintended hits against classes that just happen to have a method with one of these names.

do you meaning that b get should not match getters of computed properties, only functions/methods actually named get?

[kastiglione]

@swift-ci test windows

[kastiglione]

@swift-ci test

[jimingham]

I missed where this came in the breakpoint flow, I thought it would add hits not candidates. Since it's just adding candidates, the user gets to choose which ones they want, so that's taken care of.

What is the flow when I have a property that doesn't have a willSet, but I set a breakpoint on willSet? The GetMethodNameVariants will add a willSet name to the list of variants, but that method doesn't actually exist. Is it clear what went on in that case?

If that's not confusing, I'm fine with this. Thanks for the test!

[kastiglione]

@swift-ci test windows

[adrian-prantl]

Is accessor "block" a term of art? I would have expected this to be called an "accessor method" or just an "accessor".

[kastiglione]

the documentation of the swift grammar calls them blocks, see "variable-declaration" in https://docs.swift.org/swift-book/documentation/the-swift-programming-language/summaryofthegrammar#Declarations

I'm fine with removing the word block though.

[kastiglione]

@swift-ci test

[adrian-prantl]

@swift-ci test windows