This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Move the SymbolizableObjectFile header to include/llvm.
ClosedPublic

Authored by snehasish on Jan 6 2022, 5:42 PM.

Details

Summary

This change moves the SymbolizableObjectFile header to
include/llvm/DebugInfo/Symbolize. Making this header available to other
llvm libraries simplifies use cases where implicit caching, multiple
platform support and other features of the Symbolizer class are not
required. This also makes the dependent libraries easier to unit test
by having mocks which derive from SymbolizableModule.

Diff Detail

Event Timeline

snehasish created this revision.Jan 6 2022, 5:42 PM
snehasish requested review of this revision.Jan 6 2022, 5:42 PM
Herald added a project: Restricted Project. · View Herald TranscriptJan 6 2022, 5:42 PM
tejohnson accepted this revision.Jan 7 2022, 8:29 AM

lgtm

llvm/include/llvm/DebugInfo/Symbolize/SymbolizableObjectFile.h
95

Suggest removing the formatting change so it is clear this is just a file move.

This revision is now accepted and ready to land.Jan 7 2022, 8:29 AM
snehasish updated this revision to Diff 398236.Jan 7 2022, 2:13 PM

Revert formatting change to the header.

snehasish marked an inline comment as done.Jan 7 2022, 2:14 PM

@dblaikie

Moving classes from .cpp to .h usually requires some mechanism to prevent folks (who are making refactorings) from undoing the change.
This can sometimes by done by having a unit test.

@dblaikie

Moving classes from .cpp to .h usually requires some mechanism to prevent folks (who are making refactorings) from undoing the change.
This can sometimes by done by having a unit test.

If the new use is going to be out-of-tree, that's generally a good idea - but in this case the new use is in-tree in subsequent patches in this patch series I think, so I think it's OK as-is? (once the rest of the patch series is in, it'll be clear that folding this back into the .cpp won't be feasible since there'll be multiple callers.

MaskRay accepted this revision.Jan 7 2022, 4:59 PM

Ah, I missed that this is for in-tree change. Then this is fine to me.

D116782 does not seem to be related to this patch, so the relation may need to be removed.

Thanks for taking a look @MaskRay and @dblaikie. I've updated the child revision to point to the correct dependent patch.

This revision was landed with ongoing or failed builds.Feb 3 2022, 2:38 PM
This revision was automatically updated to reflect the committed changes.