[libcxx-commits] [PATCH] D157058: [libc++] Remove generic char_traits implementation
Corentin Jabot via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed Sep 13 11:31:27 PDT 2023
cor3ntin added a comment.
The challenges here is that `char_traits` is both declared and instantiated in a system header.
We need a logic to somehow realize that the instantiation of `char_traits` was ultimately caused by user code.
Ideally, an instantiation of `char_traits` in a system header that is not caused by a user in some way would not produce warning.
So we need to walk back the stack of instantiation to see where things originated from and probably compare the types too
Consider (purely for demonstration purpose);
1/ A scenario caused by a user-requested specialization that we want to diagnose;
//libc++:
template<typename T, typename Trait = char_trait<T>>
basic_string {};
// usercode
template basic_string<int>; // user messed up
2/ A scenario that the user is not responsible for at all, which is why we silence warnings in system headers
//libc++:
using __do_what_i_say_not_what_i_do = char_trait<int>> ;
// user code
// user can't do on anything about warnings
A scenario caused by a user-requested specialization that is still unactionable for the user
//libc++:
template<typename T, typename Trait = char_trait<double>>
basic_string {};
// usercode
template basic_string<int>; // user can't act on a warning here
We need to allow 1 and not 2 & not 3 either preferably.
Exposing the diagnostics engine to code won't help clang refine the definition of system header.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157058/new/
https://reviews.llvm.org/D157058
More information about the libcxx-commits
mailing list