`modernize-use-trailing-return-type` might show desugared type in fix-it hint for lamdba

[firewave]

Split from #144509.

#include <algorithm>
#include <vector>

void f()
{
    auto it2 = [](const std::vector<int>& v) {
        return std::find_if(v.cbegin(), v.cend(), [](int i) -> bool {
            return i == 0;
        });
    };
}

<source>:10:16: warning: use a trailing return type for this lambda [modernize-use-trailing-return-type]
   10 |     auto it2 = [](const std::vector<int>& v) {
      |                ^
      |                                              -> __gnu_cxx::__normal_iterator<const int *, std::vector<int>>

https://godbolt.org/z/zzYMa4o5r

It should be suggesting std::vector<int>::const_iterator.

[firewave]

I don's see the original sugared type preserved in the AST https://godbolt.org/z/farW8EqE3

Originally posted by @vbvictor in #144509

[llvmbot]

@llvm/issue-subscribers-clang-tidy

Author: Oliver Stöneberg (firewave)

Split from #144509.

#include <algorithm>
#include <vector>

void f()
{
    auto it2 = [](const std::vector<int>& v) {
        return std::find_if(v.cbegin(), v.cend(), [](int i) -> bool {
            return i == 0;
        });
    };
}

<source>:10:16: warning: use a trailing return type for this lambda [modernize-use-trailing-return-type]
   10 |     auto it2 = [](const std::vector<int>& v) {
      |                ^
      |                                              -> __gnu_cxx::__normal_iterator<const int *, std::vector<int>>

https://godbolt.org/z/zzYMa4o5r

It should be suggesting std::vector<int>::const_iterator.

[firewave]

It gets even weirder using libc++:

<source>:6:16: warning: use a trailing return type for this lambda [modernize-use-trailing-return-type]
    6 |     auto it2 = [](const std::vector<int>& v) {
      |                ^
      |                                              -> std::__wrap_iter<const int *>

https://godbolt.org/z/5q7a8o116

[firewave]

CC'ing @kimgr @bolshakov-a as they have insight into sugar and types - even if there is nothing to contribute, it might be of interest.

[bolshakov-a]

I don't have much expertise in clang but I suspect that preserving a type sugar may be not a trivial task, especially on type deduction. Consider a simple example:

typedef int Typedef1, Typedef2;

auto Fn(bool b, Typedef1 i1, Typedef2 i2) {
    return b ? i1 : i2;
}

Which type do you expect as the return type of Fn?

I'd rather call @mizvekov. He has done a hard work on preserving the type sugar on template instantiations.

[mizvekov]

I don't have much expertise in clang but I suspect that preserving a type sugar may be not a trivial task, especially on type deduction. Consider a simple example:

typedef int Typedef1, Typedef2;

auto Fn(bool b, Typedef1 i1, Typedef2 i2) {
    return b ? i1 : i2;
}

Which type do you expect as the return type of Fn?

I'd rather call @mizvekov. He has done a hard work on preserving the type sugar on template instantiations.

I won't have time to look at this in detail until late next week, but we should be fully preserving the type sugar with return type deduction. I suspect something else is going on in that checker.

For the example above with the ternary, this will result in the common sugar type, which in that case is just int.

You would need a common typedef between the two sides to get something else.

This common sugar is the same mechanism that is used for the return type deduction case, when there are multiple return statements.

[bolshakov-a]

we should be fully preserving the type sugar with return type deduction

Sounds encouraging! Preserving type sugar is highly desirable for e.g. IWYU tool to work well.

[mizvekov]

This is a duplicate of #144510

This is solved with template specialization resugaring.

With that solved, this will also run into #144509 as well, the checker needs to create a new nested name specifier which is usable from the fix-it context.