timon-ul wrote: > Separately I'd be curious whether you'd be open to discussing the > multi-target case. My intuition is that almost nobody is actually trying to > navigate to the make_unique definition itself, so returning both targets and > letting the client present a menu felt like a reasonable default. I get that > in vscode that breaks the navigation flow for you. clangd already has the > config infra for opt-in toggles (InlayHints, Hover, etc.), so perhaps a > Navigation.ResolveForwardingTarget flag defaulting to today's behaviour could > let people who want the menu opt in without affecting anyone else. What are > you thoughts?
As I already hinted at in my original post, I am not that sold on the current behaviour, quite honestly it is a bit painful to hit that one pixel that lets you navigate to the constructor, so I am definitely open for the discussion of different behaviour. That being said I do not believe this should be part of this PR, this PR should focus on implementing the logic and then using the "safe" behaviour that reflects how we deal with constructors now already seems perfect for it for now. The question about general behaviour should probably be held in a new issue and I would at least like to have input of more people on how they feel about this. https://github.com/llvm/llvm-project/pull/199480 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
