https://github.com/benlangmuir commented:
I'm skeptical that treating `FileEntryRef` as `FileEntry *` for the purposes of equality and hashing is a good idea. To me, the obvious interpretation of `FileEntryRef ==` is that the path must be equal, and having it based on the dev/inode is surprising. I know that's not something you're *introducing* in this PR, but I would prefer we remove that functionality rather than build more on top of it. Here are some alternative ways we could handle this that I think are more principled: * We could do `DenseMap<FileEntry *, FileEntryRef>` instead of the DenseSet, and similarly embed the FileEntryRef into the RHS type in cases with DenseMap * Alternatively, we could add a wrapper type for FileEntryRef that continues to have the `FileEntry *` equality/hashing semantics, but where the name of that wrapper and/or the fact you need to unwrap it explicitly makes it obvious that the semantics are not "just" FileEntryRef. If we can figure out a good name for this I think it would be a good solution. 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
