https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83333
Bug ID: 83333
Summary: Incorrect demangling of lambda destructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: demangler
Assignee: unassigned at gcc dot gnu.org
Reporter: nfitzgerald at mozilla dot com
Target Milestone: ---
Originally filed as https://sourceware.org/bugzilla/show_bug.cgi?id=22547
Input symbol:
```
_ZZZN7mozilla12MediaManager12GetUserMediaEP18nsPIDOMWindowInnerRKNS_3dom22MediaStreamConstraintsEP33nsIDOMGetUserMediaSuccessCallbackP31nsIDOMGetUserMediaErrorCallbackNS3_10CallerTypeEEN4$_30clERP8nsTArrayI6RefPtrINS_11MediaDeviceEEEENUlRPKcE_D1Ev
```
Actual demangling:
```
$ ./binutils/cxxfilt
'_ZZZN7mozilla12MediaManager12GetUserMediaEP18nsPIDOMWindowInnerRKNS_3dom22MediaStreamConstraintsEP33nsIDOMGetUserMediaSuccessCallbackP31nsIDOMGetUserMediaErrorCallbackNS3_10CallerTypeEEN4$_30clERP8nsTArrayI6RefPtrINS_11MediaDeviceEEEENUlRPKcE_D1Ev'
mozilla::MediaManager::GetUserMedia(nsPIDOMWindowInner*,
mozilla::dom::MediaStreamConstraints const&,
nsIDOMGetUserMediaSuccessCallback*, nsIDOMGetUserMediaErrorCallback*,
mozilla::dom::CallerType)::$_30::operator()(nsTArray<RefPtr<mozilla::MediaDevice>
>*&)::{lambda(char const*&)#1}::~nsTArray()
```
Expected demangling:
```
mozilla::MediaManager::GetUserMedia(nsPIDOMWindowInner*,
mozilla::dom::MediaStreamConstraints const&,
nsIDOMGetUserMediaSuccessCallback*, nsIDOMGetUserMediaErrorCallback*,
mozilla::dom::CallerType)::$_30::operator()(nsTArray<RefPtr<mozilla::MediaDevice>
>*&)::{lambda(char const*&)#1}::~{lambda(char const*&)#1}()
```
The https://github.com/ianlancetaylor/demangle demangler and the
`__cxa_demangle` on my OSX system agree that this symbol is a lambda's
destructor.
This makes sense to me because we're looking at a `<nested-name>` production
that parses something like:
```
<nested-name> ::= N <prefix> <unqualified-name> E
::= N <unqualified-name> <unqualifid-name> E
::= N <unnamed-type-name> <unqualified-name> E
::= N <closure-type-name> <unqualified-name> E
::= N Ul <lambda-sig> E _ <unqualified-name> E
::= N Ul <lambda-sig> E _ <ctor-dtor-name> E
::= N Ul <lambda-sig> E _ D1 E
```
I've made a reduced test case that I think shows the same issue:
```
_ZZ3aaavENUlvE_D1Ev
```
Which demangles like this:
```
$ ./binutils/cxxfilt '_ZZ3aaavENUlvE_D1Ev'
aaa()::{lambda()#1}::~aaa()
```
However, the Go demangler and my OSX system `__cxa_demangle` agree that it
should demangle to something like this:
```
aaa()::{lambda()#1}::~{lambda()#1}()
```
Note that basically the same bug occurs if I replace the lambda with a
different `<unnamed-type>`, like `Ut_`.
I'm testing with a `c++filt` I built from master a couple days ago:
```
$ ./binutils/cxxfilt --version
GNU c++filt (GNU Binutils) 2.29.51.20171201
Copyright (C) 2017 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
$ git log -1
commit 1cc75e929ff4e99b3bef4ca0e93250d5b1b126c9
Author: Yao Qi <yao...@linaro.org>
Date: Fri Dec 1 11:34:14 2017 +0000
Replace mail address with the URL in copyright header
The copyright header in most of GDB files were changed from mail address
to the URL in the conversion to GPLv3 in Aug 2007. However, some files
still use mail address instead of the URL. This patch fixes them.
gdb/testsuite:
2017-12-01 Yao Qi <yao...@linaro.org>
* gdb.arch/aarch64-atomic-inst.exp: Replace mail address with
the URL in copyright header.
* gdb.arch/aarch64-fp.exp: Likewise.
* gdb.arch/ppc64-atomic-inst.exp: Likewise.
* gdb.arch/ppc64-isa207-atomic-inst.exp: Likewise.
* gdb.base/expand-psymtabs.exp: Likewise.
* gdb.cp/expand-psymtabs-cxx.exp: Likewise.
* gdb.fortran/common-block.exp: Likewise.
* gdb.fortran/common-block.f90: Likewise.
* gdb.fortran/logical.exp: Likewise.
* gdb.fortran/vla-datatypes.f90: Likewise.
* gdb.fortran/vla-sub.f90: Likewise.
```
If there is any more information I can provide, please let me know. Thanks!
-------------------------------------------------------------------------
Comment #1 Tom Tromey 2017-12-07 21:54:05 UTC
On irc, Nathan agreed with this analysis and came up with this test case:
<nathan> struct X { ~X (); };
<nathan> void foo (X x) { [=] () { x; } (); }
<nathan> _ZZ3foo1XENUlvE_D1Ev
