[BoundsSafety] Make `__single` as a sugar type

[rapidsna]

Currently, the downstream implementation makes __single part of the canonical type, but we may want to keep it as a sugar type (AttributedType) since it does not change the pointer representation or ABI. This way, sized_by/counted_by/terminated_by will no longer be internally marked as a "single" PointerType.

rdar://177980903

[AnupamKumar-1]

I’ve been working on this issue and implemented a SinglePointerType sugar type following the pattern used by CountAttributedType and DynamicRangePointerType.

So far I’ve added:

• SinglePointerType in TypeBase.h inheriting from BoundsAttributedType
• Registrations in TypeNodes.td, TypeBitCodes.def, and TypeProperties.td
• ASTContext::getSinglePointerType()
• SinglePointerTypeLoc in TypeLoc.h
• Support in RecursiveASTVisitor, TreeTransform, ASTWriter, ASTReader, ASTImporter, CIndex, and TypePrinter
• VisitSinglePointerTypeLoc in DeclaratorLocFiller (SemaType.cpp)
• TransformSinglePointerType in TreeTransform.h

The implementation builds successfully. The main blocker is that wiring __single to use this sugar type (by wrapping the result of getPointerType() with getSinglePointerType() in SemaType.cpp) causes ~400 test failures. Many call sites use cast() directly and appear to assume that __single is represented as a canonical PointerType rather than a sugar wrapper.

Is there a preferred migration strategy here? Should these sites generally be updated to use getAs() (or otherwise desugar first), or is there a different approach you’d recommend?

[rapidsna]

Thanks for help! But __single should just use AttributedType, no need to create a new type for this. @delcypher on my team has been looking at this issue. So for the future, I'd appreciate if you could coordinate before you pick up the task next time, and discuss the approach in advance, so we don't duplicate work and make sure we have the right design.

[AnupamKumar-1]

@rapidsna Thanks! I'll coordinate before starting work next time.

[hnrklssn]

One approach that might work here is to still have PointerType contain bounds information. That way it won't be lost by accidentally stripping type sugar. But the original type would remain unchanged under the AttributedType as modifiedType, whereas the new canonical pointer type under equivalentType could contain bounds information (or just a flag saying it is a pointer with bounds information, to signal that it shouldn't be used as __unsafe_indexable). This would let us skip the current synthetic typedef hack we use when applying bounds attributes to typedef'd pointer types. Instead we could get the expected diagnostic printing by printing "$modifiedType $attr".

[rapidsna]

Yes, keeping modifiedType unchanged under AttributedType should fix the typedef issue.

For equivalentType though, we intentionally want it to canonicalize to the same type as __unsafe_indexable or other thin pointers. The goal is for __single and __counted_by to have the same canonical identity as raw pointers so they participate identically in overload resolution and name mangling; encoding bounds information in PointerType would defeat that. In exchange, bounds-aware consumers have to walk through AttributedType / CountAttributedType rather than rely on canonical types.

[rapidsna]

@AnupamKumar-1 Please let me know if you still want to tackle this issue with the suggested AttributedType approach.

[AnupamKumar-1]

@rapidsna Yes, I’d like to work on this issue using the suggested AttributedType approach.

[rapidsna]

@AnupamKumar-1 Thanks! I just assigned you to this issue.

[rapidsna]

@AnupamKumar-1 How things are going? Let me know if you don't want to take this anymore so we can distribute to other people.

[AnupamKumar-1]

Hi @rapidsna ! I’m still working on this and would like to keep it. I expect to have a PR ready in 3–4 days. Thanks!