On Tue, 17 Mar 2026, Jason Merrill wrote:
> 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.
FWIW I think we do need to rename non-uglified member functions still
since they can cause name lookup ambiguities, e.g. if std::vector for
some reason defines a fetch_xor then it'd break
struct A { void fetch_xor(); };
struct B : A, std::vector<int> { };
void f(B& b) { b.fetch_xor(); };
>
> > 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
>
>
