xazax.hun added a comment. 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. It is only possible to disambiguate with knowledge about the linking graph. I think that information is better to be stored in the index in the future and do the disambiguation within the library instead of making the client do that. > > >> The reason we introduced the diagnostic is that we assumed that the client >> can not recover from a configuration error and will end up reporting the >> problem to the user. > > For the static analyzer client, at least, one possible recovery is performing > the existing invalidation that we do when calling a function defined in > another translation unit. (I'm not really sure this a good idea; I just > wanted to point out that the decision probably belongs with the client). I > think it is reasonable to report an error as a diagnostic -- but I think this > should be up to the client and I don't think it should show up in the index > file itself. In an ideal world the user wouldn't even know that file existed. > Further, for large projects/incremental rebuilds a text file is unlikely to > be a suitable representation for the index. In the long term I doubt the file > will be end-user editable/readable. I agree that we do not consider this format to be final for the index. In the future, it would be great to include linking information as well and also have utilities to merge partial indexes. This is a first version to make the machinery work for the most common cases which are already pretty usable for the open source projects we tested. https://reviews.llvm.org/D34512 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
