[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