=?utf-8?q?Balázs?= Benics <[email protected]>,
=?utf-8?q?Balázs?= Benics <[email protected]>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
================
@@ -15128,8 +15128,18 @@ void
Sema::addLifetimeBoundToImplicitThis(CXXMethodDecl *MD) {
QualType AttributedType =
Context.getAttributedType(Attr, MethodType, MethodType);
TypeLocBuilder TLB;
- if (TypeSourceInfo *TSI = MD->getTypeSourceInfo())
+ TypeSourceInfo *TSI = MD->getTypeSourceInfo();
+ if (TSI && TSI->getTypeLoc().getType() == MethodType) {
TLB.pushFullCopy(TSI->getTypeLoc());
+ } else {
+ // The written type-source info can disagree with the method's type. For
+ // example, a deduced 'auto' return type in a template instantiation keeps
+ // the 'auto' placeholder in its TypeSourceInfo while the method's type has
+ // already been resolved to the deduced type. Pushing the stale TypeLoc
+ // would make the wrapping AttributedTypeLoc's inner type inconsistent with
+ // MethodType. Build a trivial TypeLoc that matches MethodType instead.
+ TLB.pushTrivial(Context, MethodType, MD->getLocation());
----------------
NeKon69 wrote:
I think the location used for creating a `TypeLoc` could be improved a bit;
practically all `pushTrivial` calls across the codebase try to preserve the
original type's source location, so we can do something similar here since the
information for that is available through `TSI`.
https://github.com/llvm/llvm-project/pull/233558
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
