================
@@ -2851,9 +2851,32 @@ ExprResult Sema::ActOnIdExpression(Scope *S,
CXXScopeSpec &SS,
// LookupName handles a name lookup from within anonymous struct.
if (LookupName(R, S)) {
if (auto *VD = dyn_cast<ValueDecl>(R.getFoundDecl())) {
+ // In C, fields inside bounds safety attributes (like __counted_by)
+ // are resolved as standalone identifiers. However, representing them
+ // as freestanding DeclRefExprs breaks downstream analyses (like
Thread Safety).
+ // Instead, we synthesize a phantom CThisExpr and immediately build a
+ // legally valid MemberExpr to represent the field access.
+ if (isa<FieldDecl>(VD) || isa<IndirectFieldDecl>(VD)) {
+ RecordDecl *RD = nullptr;
+ if (auto *FD = dyn_cast<FieldDecl>(VD))
+ RD = FD->getParent();
+ else if (auto *IFD = dyn_cast<IndirectFieldDecl>(VD))
+ RD = cast<FieldDecl>(IFD->chain().front())->getParent();
+
+ if (RD) {
+ QualType RecordTy = Context.getTypeDeclType(cast<TypeDecl>(RD));
+ QualType ThisPtrTy = Context.getPointerType(RecordTy);
+ Expr *Base = CThisExpr::Create(Context, NameLoc, ThisPtrTy);
+
+ return BuildMemberReferenceExpr(Base, ThisPtrTy, NameLoc,
+ /*IsArrow=*/true, SS,
----------------
Caryoake wrote:
yes the isArrow == true is required as we explicitly construct ThisPtrTy as a
pointer to the record. So the member reference which forms must semantically
act as an arrow access no?
The base expression should be inherently Implicit yes. Even though the user may
type the field explicitly (for eg:- count or size), the resolution logic which
turns into a member access is implicit.
https://github.com/llvm/llvm-project/pull/199241
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
