[clang] Extend pointer interpretation handling to track explicitness

[jrtc27]

We need a new type like DependentPointerType for non-dependent contexts
that can track __capability applied to things like typeof(...) in order
to have a corresponding TypeLoc for the qualifier, otherwise things like
TypeSpecLocFiller get out of sync and, in some cases assert (in other
cases silently use the wrong DeclSpec). However, this then exposes the
fact TypePrinter's PrintingPolicy's SuppressCapabilityQualifier isn't
always able to be set to the right value (e.g. when printing out a
reinterpret_cast to the user, or when dumping the AST), and so we end
up with redundant __capability qualifiers appearing for purecap code in
some cases, and so we need to track alongside the pointer interpretation
whether it was explicit (which also needs care to ensure it doesn't mess
with canonicalisation). Whilst the output is now noisier in cases where
__capability is used in purecap code, this is more faithful to the
source.

The churn in the AST output due to __capability in the source always
being sugar is an unfortunate side-effect, but this should disappear
if llvm/llvm-project#65214 is merged.

Fixes #710

[arichardson]

Not managed to review the full change yet, but I wonder if we should rename PointerInterpretationKindExplicit to PointerInterpretationKind and the give the current enum a new name to reduce the size of the diff and the length of most new lines?

[jrtc27]

Not managed to review the full change yet, but I wonder if we should rename PointerInterpretationKindExplicit to PointerInterpretationKind and the give the current enum a new name to reduce the size of the diff and the length of most new lines?

Maybe... I was struggling with naming. Also not quite happy with where it is currently, found some more issues with our handling of things (around type printing when you have multiple redundant qualifiers, and around __capability on arrays -- typedef void *T[]; T const x; is void * const x[]; not void *x[const]; like you'd think, so T __capability x[] should be void * __capability;, but actually using that syntax quickly turns into an asserting mess). Needs more love, but this is heading in the right direction, I think.

[arichardson]

Not managed to review the full change yet, but I wonder if we should rename PointerInterpretationKindExplicit to PointerInterpretationKind and the give the current enum a new name to reduce the size of the diff and the length of most new lines?

Maybe... I was struggling with naming. Also not quite happy with where it is currently, found some more issues with our handling of things (around type printing when you have multiple redundant qualifiers, and around __capability on arrays -- typedef void *T[]; T const x; is void * const x[]; not void *x[const]; like you'd think, so T __capability x[] should be void * __capability;, but actually using that syntax quickly turns into an asserting mess). Needs more love, but this is heading in the right direction, I think.

I agree this is definitely a big improvement over the current state :)

How about PointerInterpretation for the enum+bool struct and keeping PointerInterpretationKind for the enum? Considering explicit can be false I'm not sure it makes that much sense to have it in the name. Hopefully this would just a be simple search+replace without any further need for refactoring?