That sounded like a scary scenario! Fortunately, expandIfMacroId even expands source locations inside the scratch buffer correctly into a location in a real file. I added two tests for it and they seem to pass. Thank you for the hint!

Thank you for the hint! I considered this for the concept location in an AutoReturnType and the expression inside a decltype AutoReturnType. Unfortunately I could not wrap my head around what is going on in SemaType.cpp :/

Thx!

Because I would like the check to rewrite e.g. const auto f(); into auto f() -> const auto;. If I omit the check for nested local qualifiers, then those kind of declarations would be skipped.

Because I would like the check to rewrite e.g. const auto f(); into auto f() -> const auto;. If I omit the check for nested local qualifiers, then those kind of declarations would be skipped.

I don't think I understand why that's desirable though? What is it about the qualifier that makes it worthwhile to repeat the type like that?

I'm still wondering about this.

Thank you for insisting on that peculiarity! The choice is stylistically motivated to align function names:

auto f() -> int;
auto g() -> std::vector<float>;
auto& h();
const auto k();
decltype(auto) l();

vs.

auto f() -> int;
auto g() -> std::vector<float>;
auto h() -> auto&;
auto k() -> const auto; 
auto l() -> decltype(auto);

But judging from your response, this might be a surprise to users. Would you prefer having an option to enable/disable this behavior?

However, I've always struggled to understand the utility of this check (it's one I disable in every .clang-tidy configuration file I can)

I am sorry to hear that, but I have heard this from many other people as well. I am sometimes questioning myself whether it was a mistake to put this check into clang-tidy and annoy a lot of people. It might have been better as a standalone tool.

I feel like the goal of this check isn't to format code nicely, it's to modernize to using a trailing return type where that adds clarity.

I like that thinking! I started with trailing return types as a stylistic choice, but I soon realized that it indeed can add clarity by shifting away complicated return types to the end of a line where they bother me less.

But I don't think auto& func() changing into auto func() -> auto& adds clarity (I think it removes clarity because the second signature is strictly more complex than the first).

With regard to clarity, you are right. And I noted down now that I shall add an option to prevent some of these rewrites. Thank you for the feedback!