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

Iain Sandoe via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 28 02:22:04 PDT 2022


iains added a comment.

In D124287#3479484 <https://reviews.llvm.org/D124287#3479484>, @jansvoboda11 wrote:

> 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.

Presumably `ASTStructuralEquivalence` can also be used as a tie-breaker in the case of a hash collision?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D124287/new/

https://reviews.llvm.org/D124287



More information about the cfe-commits mailing list