On Thu, Sep 21, 2017 at 12:13 PM, Nathan Sidwell <nat...@acm.org> wrote:
> Guys in cc: you've looked at demangling sometime in the past, so may have an
> opinion.
>
> As alluded to in https://gcc.gnu.org/ml/gcc-patches/2017-09/msg01482.html we
> display the return type of template functions containing local objects.
> This gets easily confused with the return type of the local function itself
> (local functions appear as members of local classes). For instance:
>
> 'float Foo<int>()::X::fn()'
>
> That 'float' looks like it is the return type of X::fn, but it is not.
Indeed.
> A nested lambda case would give something like:
>
> auto float Foo<int>()::{lambda(auto:1)#1}::operator()<char>(char)
> const::X::fn()
>
> Where 'auto float' is a nonsense type and neither token is the return type
> of the X::fn function they appear to be from.
>
> For non-template functions containing local objects, the containing
> function's return type is not in the demangle. I think the same should be
> done with the template case. Showing the return type does not usually add
> additional information -- either the template fn's return type is derived
> from a template parm, in which case that'll be in the <...> portion, or it
> is non-dependent. Ambiguity will arise if one solely overloads on a
> non-dependent return type:
>
> template <typename> int Foo () {/*local_thing*/}
> template <typename> float Foo () {/*local_thing*/}
>
> It seems more useful to elide the return type than preserve fidelity for
> this kind of overloading. (note, I am not changing top-level template
> function types, those continue to have a return type)
>
> So, I extended d_encoding and d_local_name to peer inside the name it has.
> When the former has a LOCAL_NAME or the latter a TYPED_NAME, it removes the
> return type of the function. (I couldn't get the printer to DTRT, it
> stashes things on a modifier stack, and has no concept of 'top-level'.
> Teaching it that looked more complicated.)
>
> This fixes the above demangles to simply:
> Foo<int>()::X::fn()
> Foo<int>()::{lambda(auto:1)#1}::operator()<char>(char) const::X::fn()
>
> Several of the existing demangler tests contain cases of this problem, and
> are adjusted. All of them become smaller (but still several are
> unreasonably large for human eyes).
>
> Thoughts? Objections?
Another possibility would be to write {float Foo<int>()} when there's
a return type, but this seems fine.
Jason
