r.stahl added a comment. In https://reviews.llvm.org/D30691#879838, @xazax.hun wrote:
> In https://reviews.llvm.org/D30691#878830, @r.stahl wrote: > > > For my purposes I replaced the return statement of the > > compareCrossTUSourceLocs function with: > > > > return XL.getFileID() < YL.getFileID(); > > > > > > A more correct fix would create only one unique diagnostic for both cases. > > > Thank you for the report, I could reproduce this after modifying the null > dereference checker. My fear of using file IDs is that I don't know whether > they are stable. So in subsequent runs, different paths might be chosen by > the analyzer and this could be confusing to the user. I will think about a > workaround that both stable and solves this assertion. > > I see two possible ways to do the proper fix. One is to check explicitly for > this case when the same function appears in multiple translation units. A > better approach would be to have the ASTImporter handle this case. I think > the proper fix is better addressed in a separate patch. Here is my improper fix with test case. Since CTU is still an experimental feature and this is a rare case to encounter I believe it's okay to risk confusing the user, rather than keep it broken. Unfortunately I will not have the time to work on a proper fix. Repository: rC Clang https://reviews.llvm.org/D48474 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
