================
@@ -4887,9 +4887,18 @@ static TypeSourceInfo
*GetFullTypeForDeclarator(TypeProcessingState &state,
cast<AutoType>(T)->getKeyword() !=
AutoTypeKeyword::Auto ||
cast<AutoType>(T)->isConstrained())) {
- S.Diag(D.getDeclSpec().getTypeSpecTypeLoc(),
- diag::err_trailing_return_without_auto)
- << T << D.getDeclSpec().getSourceRange();
+ SourceLocation Loc = D.getDeclSpec().getTypeSpecTypeLoc();
+ SourceRange SR = D.getDeclSpec().getSourceRange();
+ if (Loc.isInvalid()) {
+ TypeSourceInfo *TSI = nullptr;
+ S.GetTypeFromParser(FTI.getTrailingReturnType(), &TSI);
+ if (TSI) {
+ TypeLoc TSILoc = TSI->getTypeLoc();
+ Loc = TSILoc.getBeginLoc();
+ SR = TSILoc.getSourceRange();
+ }
+ }
+ S.Diag(Loc, diag::err_trailing_return_without_auto) << T << SR;
----------------
Sirraide wrote:
> There is no problem with `B` itself, so I think it is fine to use the full
> range.
It’s probably fine yeah. That might end up looking a bit chaotic if the
function parameter list has e.g. 10 parameters and spans multiple lines, but
you’d run into the same problem w/ a really long trailing return type. I don’t
really have a strong opinion on this. Either option is better than including no
source range at all ;Þ
https://github.com/llvm/llvm-project/pull/115786
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
