- Instead of AppDelegate::application:didFinishLaunchingWithOptions: you will now see -[AppDelegate application:didFinishLaunchingWithOptions:]
- Also include categories in the name when printing the scopes, e.g. Class(Category) and -[Class(Category) method]
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks! This generally looks good, just need to find the right home for some of the logic.
clangd/XRefs.cpp | ||
---|---|---|
455 ↗ | (On Diff #223646) | XRefs.cpp isn't really the right place for this. It should have unit tests (rather than testing it all through hover) |
532 ↗ | (On Diff #223646) | Maybe "skip over Type/Function/ObjC methods, these are part of the local scope instead". (Not sure about "objc decl" as it seems to cover a lot of other things too) |
clangd/unittests/XRefsTests.cpp | ||
1029 ↗ | (On Diff #223646) | combine test cases with above. |
1177 ↗ | (On Diff #223646) | you've got a loop here but only one test case. Combine with the other loop or just assert directly? |
clangd/XRefs.cpp | ||
---|---|---|
461 ↗ | (On Diff #223646) | it looks like DeclPrinter::VisitObjCMethodDecl already has a similar handling. |
470 ↗ | (On Diff #223646) | again there are printers in for ObjCCategory{Impl}Decls that don't respect TerseOutput option in printing policies. It might be sensible to update them instead to print an output like what you propose in here, in the presence of TerseOutput option. WDYT? |
509 ↗ | (On Diff #223646) | instead of saying what you do, could you say why you do it. IIUC, it is because the relevant bits of the container is already printed in getNameForObjCMethod right? |
Will revisit this once more critical fixes are in (crash fixes), I'm still not sure where this sort of stuff should belong
clangd/XRefs.cpp | ||
---|---|---|
461 ↗ | (On Diff #223646) | DeclPrinter::VisitObjCMethodDecl prints the declaration itself, e.g.: - (void)someMethod:(int)param; it wouldn't make sense to instead of that do -[MyClass someMethod:] for the declaration itself |
470 ↗ | (On Diff #223646) | What method names are you looking at? I wasn't able to find them |
We'll also want to do something similar for DocumentSymbols, see here, which will lead to Objective-C categories showing up as either (anonymous) or <category name>
I think there's still some more work to be done after this which might move some of this around:
I messed around with qualified name changes - lots of things internally rely upon the qualified names so that will be best for a separate change. I could potentially handle DocumentSymbol fixes in here though - LMK if you think it makes sense to move some of this logic in AST.cpp (clangd). objcContainerLocalScope seems like it would be useful to generalize support for objc container decls by ensuring that categories becoming fully qualified with their class name.
Sorry for losing this.
LMK if you think it makes sense to move some of this logic in AST.cpp (clangd). objcContainerLocalScope seems like it would be useful to generalize support for objc container decls by ensuring that categories becoming fully qualified with their class name
Yes, please move these to AST.cpp, maybe rename to printObjCMethod and printObjCContainer.
clang-tools-extra/clangd/Hover.cpp | ||
---|---|---|
62 | this function's name doesn't really describe what it's for it has 3 callsites and is only needed in 2, just inline it? | |
69 | looking at the implementation, this is null iff the method is part of a protocol. | |
76 | prefer CID->getName(), the operator<< is really surprising here | |
78 | nit: Method->getSelector().print(OS << ' '); (yeah, the implementation is dumb, but maybe they'll fix it) | |
83 | you're neither flushing nor destroying the OS, this is fragile. (From playing with godbolt, it looks like this works as long as move-elision kicks in, but adding if (false) return "" at the top prevents the stream from being flushed here) | |
94 | can't you return objcContainerLocalScope(CI->getCategoryDecl()) ? | |
150 | nit: isa<ObjCMethodDecl, ObjCContainerDecl>(DC) I'm not sure the comment adds much here (particularly "we return an empty string") - maybe remove? |
- Address review comments
Will move over to AST.cpp in next update
clang-tools-extra/clangd/Hover.cpp | ||
---|---|---|
62 | Worth keeping, see below, Open to naming suggestions =) | |
69 | It can also be NULL for invalid code (in category). Since we only call this for Decls in this decl context protocols can't ever appear as protocols can't have method definitions. Do you think it's still worth handling? | |
94 | As noted in getCategoryDecl() the class interface can be NULL when working with invalid code. |
this function's name doesn't really describe what it's for
it has 3 callsites and is only needed in 2, just inline it?