This patch removes the necessity to access the SourceLocation internal
representation in several places that use FoldingSet objects.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
| clang/include/clang/Basic/SourceLocation.h | ||
|---|---|---|
| 183–184 | Seems a bit strange to me to add SourceLocation::Profile. Is there another hook available for FoldingSet that works with free functions, or template specializations? You could make that hook a friend in order to give it access to the internals. Or can the caller just use getHashValue()? | |
| 243–245 | I'm not sure you need this change since you don't need to give access to internals here. | |
| clang/lib/Analysis/PathDiagnostic.cpp | ||
|---|---|---|
| 1088 | I'm surprised you need this static_cast, can you explain why it was necessary? | |
| clang/lib/Analysis/PathDiagnostic.cpp | ||
|---|---|---|
| 1088 | Loc is an object of type FullSourceLoc, a class derived from SourceLocation. When the FoldingSetNodeID::Add template method is called with Loc it tries to instantiate FoldingSetTrait<FullSourceLoc> and fails (because there is no explicit specialization for FullSourceLoc and the default one relies on the method FullSourceLoc::Profile which does not exist). FullSourceLoc does not contain any additional information about the location itself (it just holds a pointer to the associated SourceManager), so there is no need to specialize FoldingSetTrait for it, and casting to SourceLocation will make FoldingSetNodeID::Add use the correct FoldingSetTrait specialization. | |
LGTM.
| clang/lib/Analysis/PathDiagnostic.cpp | ||
|---|---|---|
| 1088 | Right, that makes sense. Thanks for explaining! | |
Seems a bit strange to me to add SourceLocation::Profile. Is there another hook available for FoldingSet that works with free functions, or template specializations? You could make that hook a friend in order to give it access to the internals. Or can the caller just use getHashValue()?