[PATCH] D124287: [modules][ODRHash] Compare ODR hashes to detect mismatches in duplicate ObjCInterfaceDecl.

Jan Svoboda via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 28 02:19:17 PDT 2022

jansvoboda11 added a comment.

In D124287#3476040 <https://reviews.llvm.org/D124287#3476040>, @vsapsai wrote:

> In D124287#3474369 <https://reviews.llvm.org/D124287#3474369>, @jansvoboda11 wrote:
>> This sounds reasonable to me. What use-cases does `ASTStructuralEquivalence` fit better than ODR hashes?
> I think the biggest advantage of `ASTStructuralEquivalence` is that it doesn't affect memory consumption by Decls. But it makes repeated comparisons more expensive.
> Another `ASTStructuralEquivalence` advantage is that it's easier to add new checks. For example, comparing ivars is pretty trivial with `ASTStructuralEquivalence` but with ODR hash we need to handle that ivar types can be structs/unions, including anonymous and nested structs.
> Cannot say that for sure but I think `ASTStructuralEquivalence` is easier to extend and to adopt for different purposes, while ODR hash seems to be more invasive. But this argument is more hand-wavy.
> Most likely `ASTStructuralEquivalence` has other positive qualities but that's what I was able to come up off the top of my head. And you can see that in my decision-making `ASTStructuralEquivalence` doesn't look like a compelling option.

Makes sense. If most `Decl` classes had the member variables that enable ODR hashing, would it make sense to keep structural equivalence logic around? That sounds a bit redundant to me.

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list