This is an archive of the discontinued LLVM Phabricator instance.

[ODRHash] Hash `ObjCProtocolDecl` and diagnose discovered mismatches.
ClosedPublic

Authored by vsapsai on Jul 21 2022, 7:50 PM.

Diff Detail

Event Timeline

vsapsai created this revision.Jul 21 2022, 7:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 7:50 PM
Herald added a subscriber: ributzka. · View Herald Transcript
vsapsai requested review of this revision.Jul 21 2022, 7:50 PM
Herald added a project: Restricted Project. · View Herald TranscriptJul 21 2022, 7:50 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
vsapsai added a subscriber: Restricted Project.

Should we also update ODRHash::isDeclToBeProcessed?

clang/lib/AST/ODRDiagsEmitter.cpp
313

Are we okay with simply comparing protocol names here instead of the full declarations? I guess we're relying on the top-level diagnostic for those, and avoiding recursing, correct?

1660

This will fall-through and call llvm_unreachable, will it not? I assume that's not intended.

Should we also update ODRHash::isDeclToBeProcessed?

No, as isDeclToBeProcessed is only for sub-decls and protocols cannot be nested inside other entities. Looks like nested protocols are rejected at the parsing stage※, so I won't test such case.

Your comment is valuable as it reveals bad naming and I plan to rename isDeclToBeProcessed to isSubDeclToBeProcessed in a separate commit (suggestions for alternative names are welcome).

Footnotes

※ - code like

@protocol Foo
@protocol Bar
@end
@end

is rejected with errors

test.m:2:1: error: illegal interface qualifier
@protocol Bar
^
test.m:3:2: error: unknown type name 'end'
@end
 ^
test.m:4:2: error: prefix attribute must be followed by an interface, protocol, or implementation
@end
 ^
test.m:4:5: error: missing '@end'
@end
    ^
test.m:1:1: note: protocol started here
@protocol Foo
^
clang/lib/AST/ODRDiagsEmitter.cpp
313

The main reason to compare just names is so that we don't fail with forward-declared protocols that don't have full declarations (covered by tests). And yes, we are relying on the top-level diagnostic to find mismatches in the referenced protocols.

Note that we have the same behavior in ODRHash::AddObjCProtocolDecl.

1660

Good question. Protocols cannot have fields or vars (properties are covered by D130326). Typedefs are top-level and not nested inside protocols, so that case cannot happen too. Other is covered by FirstDiffType == Other || SecondDiffType == Other and EndOfClass by FirstDiffType != SecondDiffType. So it is correct that in all of these cases we fall-through to llvm_unreachable.

jansvoboda11 accepted this revision.Oct 11 2022, 6:50 PM

Thanks for explaining. This LGTM, but you might want to get a second opinion.

clang/lib/AST/ODRDiagsEmitter.cpp
1660

That makes sense, thanks for the explanation. Can you a short summary in a comment?

This revision is now accepted and ready to land.Oct 11 2022, 6:50 PM
bruno accepted this revision.Oct 14 2022, 5:31 PM
bruno added a subscriber: bruno.

Great to see both this and D130325 landing, LGTM too.

This revision was landed with ongoing or failed builds.Oct 17 2022, 4:30 PM
This revision was automatically updated to reflect the committed changes.

Thanks for the reviews!