[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