This is an archive of the discontinued LLVM Phabricator instance.

[ODRHash diagnostics] Move `ODRDiagsEmitter` to libAST in separate files. NFC.
ClosedPublic

Authored by vsapsai on Jun 27 2022, 8:08 PM.

Details

Summary

Intend to use ODRDiagsEmitter during parsing to diagnose a parsed
definition differing from a definition with the same name from a hidden
[sub]module.

Diff Detail

Event Timeline

vsapsai created this revision.Jun 27 2022, 8:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 8:08 PM
vsapsai requested review of this revision.Jun 27 2022, 8:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2022, 8:08 PM
Herald added a subscriber: cfe-commits. · View Herald Transcript
vsapsai added a subscriber: Restricted Project.

If anybody knows how to demonstrate the code was moved without modification in process, I'll be happy to do that. Unfortunately, the only thing I've found is that it should be auto-detected.

It looks like we lack a patch to use it in parser, right?

It looks like we lack a patch to use it in parser, right?

Kinda. Things get a little bit more complicated before we can do that. But to see the bigger picture, I've published all planned intermediate steps with the final D130327. And there in clang/lib/Parse/ParseObjc.cpp you can see how ODRDiagsEmitter is used in the parser.

I'm not opening those patches for review yet as I want to polish them a little bit and to test all of this stuff on real projects. Landing all of NFC stuff should be sufficient to start testing.

I see. It looks like the tricks in .git-blame-ignore-revs doesn't work for this kind of move. I admit I don't look these changes in details. But as long as it is helpful for future changes, I think it should be good.

vsapsai updated this revision to Diff 447905.Jul 26 2022, 6:13 PM

Rebase on top of the previous change in the stack.

I see. It looks like the tricks in .git-blame-ignore-revs doesn't work for this kind of move. I admit I don't look these changes in details. But as long as it is helpful for future changes, I think it should be good.

Yeah, looks like these kind of changes in git blame should be handled by flags -C and -M and not by ignoring revisions.

ChuanqiXu accepted this revision.Jul 28 2022, 7:59 PM

If the code motion is helpful for further changes, it should be good.

This revision is now accepted and ready to land.Jul 28 2022, 7:59 PM
This revision was landed with ongoing or failed builds.Sep 7 2022, 2:41 PM
This revision was automatically updated to reflect the committed changes.