ObjCPropertyDecl should use the category interface as a context similar to what is done for methods.
Previously category methods would be printed as ::property; now they are printed as Class::property.
This is definitely an improvement, though I don't know if it's *right*. @akyrtzi, thoughts?
One concern is that similarly-named members in extensions of different classes will have the same name (whereas categories have names, so the collision is less likely).
Obj::(class extension)::property might be a more useful QName (including *also* the class name).
(class extension)::property is definitely an improvement over the current ::property, though.
Yeah, I'm not sure what the desired behavior is. When writing up the test I noticed there is a Obj::property, presumably for the auto-generated getter method (which I then filtered out via objcPropertyDecl).
Where is the qualified name used?
Do you know if this have an effect on the output of completion results or other tooling-based output?
A couple of requests:
It's possible - clangd for instance was crashing because of the current behavior: ::property instead of Obj::property or (class extension)::property.
For more context here: I'm seeing similar issues for Objective-C instance variables (they can be declared inside a class extension --> meaning the Decl has no name --> clangd fails with an assertion that the name shouldn't be empty).
It seems to me that for Objective-C we could do something like Obj(Extension::property or alternatively Obj(Extension).property and Obj(class extension)->_instanceVar, but I'm not sure about what relies upon this current behavior (if anything).