fitermay 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.
@timon-ul Fully, agree. It was not my intention to have that in scope of this PR. https://github.com/llvm/llvm-project/pull/199480 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
