[clang][Tooling] Get rid of a hack in SymbolOccurrences, NFCI

[miyuki]

Summary

The class SymbolOccurrences can store either a single SourceRange
in-place or multiple SourceRanges on the heap. In the latter case
the number of source ranges is stored in the internal representation
of the beginning SourceLocation of the in-place SourceRange
object.

This change gets rid of such hack by placing SourceRange in a union
which holds either a valid SourceRange or an unsigned int (a number
of ranges).

The change also adds static_asserts that check that SourceRange and
SourceLocation are trivially destructible (this is required for the
current patch and for D94237 which has already been committed).

[miyuki]

I will wait until the end of this week to see if anyone has objections.

[simon_tatham]

clang/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h

81

This surely relies on SourceRange having no destructor (or rather, a trivial one). If that ever changes, then destruction of this class will risk either a spurious call to the destructor or a missing one.

Is there any way to somehow arrange that a build failure will occur if the definition of SourceRange changes in that way?

[simon_tatham]

clang/include/clang/Tooling/Refactoring/Rename/SymbolOccurrences.h

81

... aha, found one. Such as a static assertion that std::is_trivially_destructible<clang::SourceLocation>::value is 1.

[miyuki]

Added static_asserts that check that SourceRange and SourceLocation are trivially destructible.

[simon_tatham]

Thanks. LGTM now.