jansvoboda11 wrote: I understand your concern, we should definitely look into this. However, I think the inode uniquing functionality is pretty fundamental to `FileEntry`, so I'm not sure it's reasonable for type named `FileEntryRef` to do anything else. I guess we could split `FileEntryRef` into two types that make it super clear whether they have the same uniquing semantics or not.
But, since we're only 5 more commits away from finally finishing the whole `FileEntry` to `FileEntryRef` transition, I think it would be more pragmatic to keep the status quo in this patch (it's been in place [since 2020](https://reviews.llvm.org/D92627)), finish the transition, and come up with the next steps after that's done. Note that none of the other 5 commits introduce any more usages of `FileEntryRef` in associative containers. What do you think? https://github.com/llvm/llvm-project/pull/67742 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
