On 3/17/26 2:09 PM, Jakub Jelinek wrote:
On Tue, Mar 17, 2026 at 05:11:42PM +0100, Jakub Jelinek wrote:
The following patch adds a plugin (sorry, to check-g++ testsuite rather
than libstdc++ testsuite because in plugin.exp we have all the needed
infrastructure.
Here is a new version of the patch. It now adds automatic whitelisting
(basically, any identifier (except for namespace identifiers, sorry) it sees
inside
of std namespace and nested namespaces in it (excluding non-inline
namespaces with _ prefixed names) during the namespace and class and
also enumerators walk are whitelisted, and non-uglified name diagnostics
is deferred until end of TU at which point were report the non-whitelisted
ones one way and whitelisted ones another way which doesn't fail the
testcase). And it does diagnose badnames and non-uglified names of
functions/classes etc. even in the implementation non-inline namespaces
like std::__gnu_cxx etc.
With the patch Jonathan posted, the results are (if you see something that
looks like a bug in the plugin, please let me know including details why and
I'll try to fix it):
libstdc++-v3/include/bits/atomic_base.h:1137:7: note: non-uglified name
'is_lock_free'
libstdc++-v3/include/bits/atomic_base.h:1145:7: note: non-uglified name 'store'
libstdc++-v3/include/bits/atomic_base.h:1152:7: note: non-uglified name 'load'
libstdc++-v3/include/bits/atomic_base.h:1173:7: note: non-uglified name
'compare_exchange_weak'
libstdc++-v3/include/bits/atomic_base.h:1183:7: note: non-uglified name
'compare_exchange_strong'
libstdc++-v3/include/bits/atomic_base.h:1220:7: note: non-uglified name
'fetch_add'
libstdc++-v3/include/bits/atomic_base.h:1225:7: note: non-uglified name
'fetch_sub'
libstdc++-v3/include/bits/atomic_base.h:1230:7: note: non-uglified name
'fetch_and'
libstdc++-v3/include/bits/atomic_base.h:1235:7: note: non-uglified name
'fetch_or'
libstdc++-v3/include/bits/atomic_base.h:1240:7: note: non-uglified name
'fetch_xor'
I don't think we need to gratuitously change the names of existing
functions. Especially when the names are shared with standard APIs, so
should be safe from macros.
libstdc++-v3/include/bits/basic_string.h:3874:45: note: non-uglified name
'allocator_type'
libstdc++-v3/include/bits/deque.tcc:1356:47: note: non-uglified name
'difference_type'
libstdc++-v3/include/bits/hashtable_policy.h:605:5: note: non-uglified name
'max_load_factor'
libstdc++-v3/include/bits/hashtable_policy.h:682:5: note: non-uglified name
'max_load_factor'
libstdc++-v3/include/bits/streambuf_iterator.h:441:60: note: non-uglified name
'traits_type'
libstdc++-v3/include/bits/streambuf_iterator.h:442:60: note: non-uglified name
'streambuf_type'
libstdc++-v3/include/bits/streambuf_iterator.h:443:60: note: non-uglified name
'int_type'
libstdc++-v3/include/bits/streambuf_iterator.h:488:60: note: non-uglified name
'traits_type'
libstdc++-v3/include/bits/streambuf_iterator.h:489:60: note: non-uglified name
'streambuf_type'
libstdc++-v3/include/bits/streambuf_iterator.h:490:60: note: non-uglified name
'int_type'
And we certainly don't want to change public member names which are
required by the standard.
Jason
