Reconcile changes from upstream PR to introduce CThisExpr

[rapidsna]

Upstream PR: llvm#199241
Related upstream issue: llvm#197250

What upstream is changing

The PR introduces a new CThisExpr AST node — a C-side analogue of
CXXThisExpr — so that field references inside C bounds-safety and
thread-safety attribute arguments (e.g. __counted_by(size),
__sized_by(...), guarded_by(...)) are represented as a proper
MemberExpr with a CThisExpr base, instead of the current hack of
using a DeclRefExpr that points directly at a FieldDecl.

The upstream motivation is that a DeclRefExpr → FieldDecl is not a
legal AST shape and crashes type builders such as
BuildCountAttributedArrayOrPointerType.

Why this matters for swiftlang/llvm-project

Downstream has a full -fbounds-safety implementation which relies on the DeclRefExpr → FieldDecl AST shape. We will need to migrate those to the CThisExpr → MemberExpr shape.

Goal

Pull CThisExpr into swiftlang/llvm-project/next before the
upstream PR merges, so that our downstream field-reference representation is aligned with the direction upstream is taking, avoiding a large one-shot rebase later.

[abhijeetsharma200]

Hey, before I begin investigating. I just want to confirm if the upstream PR is largely ready to be merged.

[rapidsna]

@abhijeetsharma200 Good question! The upstream PR is awaiting another round of review llvm#199241 so it will depend on whether the other reviewers are happy with the updates. Regardless, the approach to use a new AST node (CThisExpr) won't likely change so we need someone to investigate how big of the impact will be on downstream if we apply this approach for the full -fbounds-safety implementation.

[abhijeetsharma200]

Thanks for the response! I will investigate the size of the impact of CThisExpr in downstream.

I do have another question.

The upstream motivation is that a DeclRefExpr → FieldDecl is not a
legal AST shape and crashes type builders such as
BuildCountAttributedArrayOrPointerType.

If this is true upstream, why doesn't the same crash happen downstream? I believe llvm/main is regularly pulled into swiftlang/next. So, shouldn't the flow have been that it causes a crash downstream, and then the approach is fixed downstream and then later upstreamed? I must be missing something here.

[rapidsna]

@abhijeetsharma200 Sorry I missed this. Good question. In downstream we had some hacky workaround to just allow DeclRefExpr → FieldDec for -fbounds-safety, which is not a good long-term fix. And it still hits some crashes in some corner cases and/or as new code is introduced from upstream. Does it make sense?

[abhijeetsharma200]

Hey, thanks for the response. Yes, that does make sense. Just FYI, I am pretty busy for the next two days, but I should have completed the investigation by the end of this weekend. Thanks for your patience!