[clang] [lldb] [BoundsSafety] Introduce LateParsedAttrType AST placeholder type (PR #204125)

Yeoul Na via cfe-commits cfe-commits at lists.llvm.org
Tue Jun 23 10:57:26 PDT 2026


================
@@ -3751,6 +3754,17 @@ QualType ASTContext::getCountAttributedType(
   return QualType(CATy, 0);
 }
 
+QualType ASTContext::getLateParsedAttrType(
+    QualType WrappedTy, LateParsedTypeAttribute *LateParsedAttr) const {
+  QualType CanonTy = getCanonicalType(WrappedTy);
+
+  auto *LPATy = new (*this, alignof(LateParsedAttrType))
+      LateParsedAttrType(WrappedTy, CanonTy, LateParsedAttr);
----------------
rapidsna wrote:

@efriedma-quic Thanks! I want to make sure we're aligned on the problem. After late parsing, LateParsedAttrType is replaced by CountAttributedType, which is also sugar that canonicalizes to the bare pointer, so canonical-type comparison already treats `int * __counted_by(n)` and plain `int *` as the same type. Bounds compatibility is checked by a separate pass that walks sugar.

The case I can see still being problematic is a sugar walker, e.g. the bounds-compatibility checker, or any consumer that asks "does this type carry __counted_by?", running during the late-parsing window. Such a walker would need to recognize LateParsedAttrType and treat it as "unresolved" rather than "no attribute here." Is that the scenario you're concerned about, or do you have a different one in mind?

If that's the right framing, the fix would be to make LateParsedAttrType its own canonical type and propagate a TypeDependence-style bit through composite types, similar to how dependent types work for templates. So any consumer can cheaply detect "unresolved late-parsed attribute somewhere inside" and defer.

https://github.com/llvm/llvm-project/pull/204125


More information about the cfe-commits mailing list