xazax.hun added a comment. In https://reviews.llvm.org/D34512#856821, @benlangmuir wrote:
> In https://reviews.llvm.org/D34512#856301, @xazax.hun wrote: > > > In https://reviews.llvm.org/D34512#856184, @dcoughlin wrote: > > > > > In either case, the important scenario I think we should support is > > > choosing at a call site to a C function the most likely definition of the > > > called function, based on number and type of parameters, from multiple > > > possible definitions in other translation units. If the API is rich > > > enough to support this then I think that is a good indication it will be > > > useful for other scenarios as well. > > > > > > Note that the lookup is already based on USR which is similar to mangled > > names in a sense that it contains information about the function > > parameters. So the only way to get multiple candidates from the lookup is > > having multiple function definitions with the same signature. > > > I just want to clarify that C function USRs do not contain type information, > although C++ USRs do. Just double checked and indeed: https://github.com/llvm-mirror/clang/blob/master/lib/Index/USRGeneration.cpp#L236 Thank you for the clarification, it looks like I did not notice this detail. In this case, it might make sense to let the client disambiguate. https://reviews.llvm.org/D34512 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
