Warnings due to `std::reverse_iterator` using the deprecated `std::iterator`

[JohelEGP]

In module 'cpp2.util' imported from /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:12:
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' is deprecated [-Wdeprecated-declarations]
   53 |     : public iterator<typename iterator_traits<_Iter>::iterator_category,
      |              ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:542:40: note: in instantiation of template class 'std::__1::reverse_iterator<jegp::command *>' requested here
  542 |     std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_));
      |                                        ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>::operator()' requested here
   86 |       __rollback_();
      |       ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>::~__exception_guard_exceptions' requested here
  137 |   return __exception_guard<_Rollback>(std::move(__rollback));
      |          ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:560:12: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>' requested here
  560 |       std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2));
      |            ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:603:26: note: in instantiation of function template specialization 'std::__uninitialized_allocator_copy_impl<std::__1::allocator<jegp::command>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, jegp::command *>' requested here
  603 |     auto __result = std::__uninitialized_allocator_copy_impl(__alloc, __unwrapped_range.first, __unwrapped_range.second, std::__unwrap_iter(__first2));
      |                          ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/vector:1145:22: note: (skipping 5 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
 1145 |   __tx.__pos_ = std::__uninitialized_allocator_copy(__alloc(), __first, __last, __tx.__pos_);
      |                      ^
/home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:57: note: in instantiation of function template specialization 'std::__1::ranges::to<std::__1::vector, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here
  100 |     return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make));  }
      |                                                         ^
/home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:42: note: in instantiation of requirement here
  100 |     return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make));  }
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:72: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE'
  373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...)          CPP2_UFCS_(&,QUALID,template,__VA_ARGS__)
      |                                                           ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:39: note: expanded from macro 'CPP2_UFCS_'
  363 |     requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \
      |              ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:35: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG'
  345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); }
      |               ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:306:34: note: expanded from macro 'CPP2_UFCS_REMPARENS'
  306 | #define CPP2_UFCS_REMPARENS(...) __VA_ARGS__
      |                                  ^
/home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:12: note: while substituting template arguments into constraint expression here
  100 |     return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make));  }
      |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:59: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE'
  373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...)          CPP2_UFCS_(&,QUALID,template,__VA_ARGS__)
      |                                                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:14: note: expanded from macro 'CPP2_UFCS_'
  363 |     requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \
      |              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:4: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG'
  345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); }
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: while checking constraint satisfaction for template 'operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' required here
  100 |     return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make));  }
      |                                                                         ^
/home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: in instantiation of function template specialization 'jegp::command::range_from_array_arguments(std::vector<std::string>)::(anonymous class)::operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/iterator.h:24:29: note: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' has been explicitly marked deprecated here
   24 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator
      |                             ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:941:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
  941 | #    define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
      |                                         ^
/home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:914:49: note: expanded from macro '_LIBCPP_DEPRECATED'
  914 | #      define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
      |                                                 ^

[ravilpatel]

The warning you're seeing is related to the use of std::iterator in the std::reverse_iterator class, and it indicates that iterator <std::random_access_iterator_tag, jegp::command> is deprecated.

This warning is likely triggered by your use of the std::reverse_iterator in combination with certain algorithms or constructs in your code.

[JohelEGP]

Yes, a very indirect use, by using std::ranges::to<std::vector>.

[mordante]

@var-const has this been introduced by your ranges to patch?

[ldionne]

@JohelEGP Can you please share how and what you're building in a reproducer? Ideally a godbolt link would make it really easy for us to see what's wrong.

[JohelEGP]

I build Libc++ according to https://libcxx.llvm.org/Modules.html#using-in-external-projects. Then building this simple program reproduces:

import std;

int main() {
  std::vector<int> v;
  v.reserve(0);
}

[ldionne]

This doesn't happen if we're not building with modules: https://godbolt.org/z/vxYPabq5h

@mordante Do you think you could have a first look?

[mordante]

As far as I can see we properly push and pop the deprecated diagnostic status. @cor3ntin could this be related to https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890?

It looks like pushing and popping the diagnostics state for deprecated messages is not working properly when using modules.

[cor3ntin]

It appears we do not currently have a way to identify "system modules", amd all modules are considered user code, I think. II have no idea how hard it would be to add that though. @ChuanqiXu9 ?

[llvmbot]

@llvm/issue-subscribers-clang-modules

Author: Johel Ernesto Guerrero Peña (JohelEGP)

```output In module 'cpp2.util' imported from /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:12: /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' is deprecated [-Wdeprecated-declarations] 53 | : public iterator<typename iterator_traits<_Iter>::iterator_category, | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:542:40: note: in instantiation of template class 'std::__1::reverse_iterator<jegp::command *>' requested here 542 | std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>::operator()' requested here 86 | __rollback_(); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>::~__exception_guard_exceptions' requested here 137 | return __exception_guard<_Rollback>(std::move(__rollback)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:560:12: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>' requested here 560 | std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:603:26: note: in instantiation of function template specialization 'std::__uninitialized_allocator_copy_impl<std::__1::allocator<jegp::command>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, jegp::command *>' requested here 603 | auto __result = std::__uninitialized_allocator_copy_impl(__alloc, __unwrapped_range.first, __unwrapped_range.second, std::__unwrap_iter(__first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/vector:1145:22: note: (skipping 5 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) 1145 | __tx.__pos_ = std::__uninitialized_allocator_copy(__alloc(), __first, __last, __tx.__pos_); | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:57: note: in instantiation of function template specialization 'std::__1::ranges::to<std::__1::vector, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:42: note: in instantiation of requirement here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:72: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:39: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:35: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:306:34: note: expanded from macro 'CPP2_UFCS_REMPARENS' 306 | #define CPP2_UFCS_REMPARENS(...) __VA_ARGS__ | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:12: note: while substituting template arguments into constraint expression here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:59: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:14: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:4: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: while checking constraint satisfaction for template 'operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' required here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: in instantiation of function template specialization 'jegp::command::range_from_array_arguments(std::vector<std::string>)::(anonymous class)::operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/iterator.h:24:29: note: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' has been explicitly marked deprecated here 24 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:941:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17' 941 | # define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:914:49: note: expanded from macro '_LIBCPP_DEPRECATED' 914 | # define _LIBCPP_DEPRECATED __attribute__((__deprecated__)) | ^ ```

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Johel Ernesto Guerrero Peña (JohelEGP)

```output In module 'cpp2.util' imported from /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:12: /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' is deprecated [-Wdeprecated-declarations] 53 | : public iterator<typename iterator_traits<_Iter>::iterator_category, | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:542:40: note: in instantiation of template class 'std::__1::reverse_iterator<jegp::command *>' requested here 542 | std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>::operator()' requested here 86 | __rollback_(); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>::~__exception_guard_exceptions' requested here 137 | return __exception_guard<_Rollback>(std::move(__rollback)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:560:12: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>' requested here 560 | std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:603:26: note: in instantiation of function template specialization 'std::__uninitialized_allocator_copy_impl<std::__1::allocator<jegp::command>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, jegp::command *>' requested here 603 | auto __result = std::__uninitialized_allocator_copy_impl(__alloc, __unwrapped_range.first, __unwrapped_range.second, std::__unwrap_iter(__first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/vector:1145:22: note: (skipping 5 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) 1145 | __tx.__pos_ = std::__uninitialized_allocator_copy(__alloc(), __first, __last, __tx.__pos_); | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:57: note: in instantiation of function template specialization 'std::__1::ranges::to<std::__1::vector, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:42: note: in instantiation of requirement here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:72: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:39: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:35: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:306:34: note: expanded from macro 'CPP2_UFCS_REMPARENS' 306 | #define CPP2_UFCS_REMPARENS(...) __VA_ARGS__ | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:12: note: while substituting template arguments into constraint expression here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:59: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:14: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:4: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: while checking constraint satisfaction for template 'operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' required here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: in instantiation of function template specialization 'jegp::command::range_from_array_arguments(std::vector<std::string>)::(anonymous class)::operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/iterator.h:24:29: note: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' has been explicitly marked deprecated here 24 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:941:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17' 941 | # define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:914:49: note: expanded from macro '_LIBCPP_DEPRECATED' 914 | # define _LIBCPP_DEPRECATED __attribute__((__deprecated__)) | ^ ```

[llvmbot]

@llvm/issue-subscribers-c-20

Author: Johel Ernesto Guerrero Peña (JohelEGP)

```output In module 'cpp2.util' imported from /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:12: /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' is deprecated [-Wdeprecated-declarations] 53 | : public iterator<typename iterator_traits<_Iter>::iterator_category, | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:542:40: note: in instantiation of template class 'std::__1::reverse_iterator<jegp::command *>' requested here 542 | std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>::operator()' requested here 86 | __rollback_(); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>::~__exception_guard_exceptions' requested here 137 | return __exception_guard<_Rollback>(std::move(__rollback)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:560:12: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<jegp::command>, jegp::command *>>' requested here 560 | std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Iter2>(__alloc, __destruct_first, __first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__memory/uninitialized_algorithms.h:603:26: note: in instantiation of function template specialization 'std::__uninitialized_allocator_copy_impl<std::__1::allocator<jegp::command>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>::__iterator<false>, jegp::command *>' requested here 603 | auto __result = std::__uninitialized_allocator_copy_impl(__alloc, __unwrapped_range.first, __unwrapped_range.second, std::__unwrap_iter(__first2)); | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/vector:1145:22: note: (skipping 5 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all) 1145 | __tx.__pos_ = std::__uninitialized_allocator_copy(__alloc(), __first, __last, __tx.__pos_); | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:57: note: in instantiation of function template specialization 'std::__1::ranges::to<std::__1::vector, std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:42: note: in instantiation of requirement here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:72: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:39: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:35: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:306:34: note: expanded from macro 'CPP2_UFCS_REMPARENS' 306 | #define CPP2_UFCS_REMPARENS(...) __VA_ARGS__ | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:12: note: while substituting template arguments into constraint expression here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:373:59: note: expanded from macro 'CPP2_UFCS_QUALIFIED_TEMPLATE' 373 | #define CPP2_UFCS_QUALIFIED_TEMPLATE(QUALID,...) CPP2_UFCS_(&,QUALID,template,__VA_ARGS__) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:363:14: note: expanded from macro 'CPP2_UFCS_' 363 | requires CPP2_UFCS_CONSTRAINT_ARG(QUALID,TEMPKW,__VA_ARGS__) { \ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/Documents/C++/Forks/hsutter/waarudo/include/cpp2util_pre.h:345:4: note: expanded from macro 'CPP2_UFCS_CONSTRAINT_ARG' 345 | || requires { CPP2_UFCS_REMPARENS QUALID __VA_ARGS__(CPP2_FORWARD(obj), CPP2_FORWARD(params)...); } | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: while checking constraint satisfaction for template 'operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' required here 100 | return CPP2_UFCS_QUALIFIED_TEMPLATE((std::ranges::),to<std::vector>)(CPP2_UFCS(std::views::transform)(std::move(v), command::make)); } | ^ /home/johel/build/Waarudo/ClangRelease/sources/jegp/algorithms/algorithms.cpp:100:73: note: in instantiation of function template specialization 'jegp::command::range_from_array_arguments(std::vector<std::string>)::(anonymous class)::operator()<std::__1::ranges::transform_view<std::__1::ranges::owning_view<std::__1::vector<std::__1::basic_string<char>>>, jegp::command (*)(std::__1::basic_string<char>)>>' requested here /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__iterator/iterator.h:24:29: note: 'iterator<std::__1::random_access_iterator_tag, jegp::command>' has been explicitly marked deprecated here 24 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:941:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17' 941 | # define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED | ^ /home/johel/Documents/C++/Forks/llvm/libcxx-std-modules/include/c++/v1/__config:914:49: note: expanded from macro '_LIBCPP_DEPRECATED' 914 | # define _LIBCPP_DEPRECATED __attribute__((__deprecated__)) | ^ ```

[ChuanqiXu9]

It appears we do not currently have a way to identify "system modules", amd all modules are considered user code, I think. II have no idea how hard it would be to add that though. @ChuanqiXu9 ?

Oh, I missed this some how.

Yes, we don't treat std modules specially now. We can make it by adding another bit in clang::Module. I'll try to handle that.

[ChuanqiXu9]

It appears we do not currently have a way to identify "system modules", amd all modules are considered user code, I think. II have no idea how hard it would be to add that though. @ChuanqiXu9 ?

I got confused after I look into https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890.

For the reproducer:

import std;

int main() {
  std::vector<int> v;
  v.reserve(0);
}

I dumped the InstantiationLoc in the above patch and it shows it is

<mylocal-path>/main.cpp:4:5

then it looks... somewhat correct... the instantiation loc is indeed not in system headers or modules. And in fact, I feel like the original patch "looks" correct for modules since currently the std modules are basically wrappers for headers.

Also the original reproducer from the thread and the duplicated reproducer in https://github.com/llvm/llvm-project/issues/79734 shows that the instantiation location lives in the users code... so I feel more confused...

[cor3ntin]

@ChuanqiXu9 in DoEmitAvailabilityWarning we do emit some warnings for user code instantiated from within system headers.

This uses S.getSourceManager().isInSystemHeader(InstantiationLoc), which returns false (incorrectly) if InstantiationLoc is in a module.

Does that make sense?

[ChuanqiXu9]

@ChuanqiXu9 in DoEmitAvailabilityWarning we do emit some warnings for user code instantiated from within system headers.

This uses S.getSourceManager().isInSystemHeader(InstantiationLoc), which returns false (incorrectly) if InstantiationLoc is in a module.

But my problem is, the dumpped InstantiationLoc (<mylocal-path>/main.cpp:4:5) is not in the module. It is in the user's code. So S.getSourceManager().isInSystemHeader(InstantiationLoc) should return false here in my mind.

Does that make sense?

[cor3ntin]

Repro https://godbolt.org/z/4rz4rehcz Without modules https://compiler-explorer.com/z/qbP9h6hMx

[cor3ntin]

@ChuanqiXu9 a good start might be to create a module version of this test https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/warn-deprecated-specializations-in-system-headers.cpp

[ChuanqiXu9]

@ChuanqiXu9 a good start might be to create a module version of this test https://github.com/llvm/llvm-project/blob/main/clang/test/SemaCXX/warn-deprecated-specializations-in-system-headers.cpp

Yeah, I made it. And it looks like it works perfectly...

// RUN: rm -rf %t
// RUN: mkdir -p %t
// RUN: split-file %s %t
//
// RUN: %clang_cc1 -std=c++20 %t/mod.cppm -emit-module-interface -o %t/mod.pcm
// RUN: %clang_cc1 -std=c++20 %t/test.cc -fprebuilt-module-path=%t -fsyntax-only -verify

//--- header.h
#pragma clang system_header

template <typename T>
struct traits;

template <>
struct [[deprecated]] traits<int> {};

template<typename T, typename Trait = traits<T>>
struct basic_string {};

using __do_what_i_say_not_what_i_do  = traits<int> ;

template<typename T, typename Trait = traits<double>>
struct should_not_warn {};

//--- mod.cppm
module;
#include "header.h"
export module mod;
export using ::basic_string;
export using ::should_not_warn;

//--- test.cc
import mod;
basic_string<int> test1; // expected-note {{in instantiation of default argument for 'basic_string<int>' required here}}
// expected-note@header.h:7 {{'traits<int>' has been explicitly marked deprecated here}}
// expected-warning@header.h:9 {{'traits<int>' is deprecated}}
should_not_warn<int> test2;

(Note that header.h is in a differrent TU of test.cc. So we can't put expected there).

Given this looks good. I'd like to commit the test directly to increase the test coverage.

---

And I am not sure if you misunderstand my point. My point is that the behavior of S.getSourceManager().isInSystemHeader(InstantiationLoc) is correct there. In the reduced example, the dumpped InstantiationLoc is test.cc so it returns false as expected. Also in the example reported from users, all the dumpped InstantiationLoc is in the user's code, so the return value of S.getSourceManager().isInSystemHeader(InstantiationLoc) is correct.

[cor3ntin]

@ChuanqiXu9 Yes, I'm a bit confused, sorry. Can we agree that isInSystemHeader returns false for locations in the std module, and that this is wrong?

I haven't found any logic in clang to handle system (standard) module.

[ChuanqiXu9]

@ChuanqiXu9 Yes, I'm a bit confused, sorry. Can we agree that isInSystemHeader returns false for locations in the std module, and that this is wrong?

Yes, it should be wrong. But my confusion point is, I didn't see the isInSystemHeader return false for locations in the std module.

For example, if I insert the following code into https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890#diff-e32ebf7695e8361164e8f353f15548838d994990b08f29778bc6aced8f2ecb01R547

if (ShouldAllowWarningInSystemHeader) {
    llvm::errs() << "Instantiation Loc:";
    InstantiationLoc.print(llvm::errs(), S.getSourceManager());
    llvm::errs() << "\n";
  }

and compile the reproducer (https://godbolt.org/z/4rz4rehcz) locally, I'll see:

Instantiation Loc:/home/chuanqi.xcq/std_modules_testing/main.cpp:4:5
In module 'std' imported from /home/chuanqi.xcq/std_modules_testing/main.cpp:1:
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, int>' is deprecated [-Wdeprecated-declarations]
   53 |     : public iterator<typename iterator_traits<_Iter>::iterator_category,
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:531:40: note: in instantiation of template class 'std::__1::reverse_iterator<int *>' requested here
  531 |     std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_));
      |                                        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>::operator()' requested here
   86 |       __rollback_();
      |       ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>::~__exception_guard_exceptions' requested here
  137 |   return __exception_guard<_Rollback>(std::move(__rollback));
      |          ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:633:14: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>' requested here
  633 |         std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Tp*>(__alloc, __destruct_first, __result));
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:994:8: note: in instantiation of function template specialization 'std::__uninitialized_allocator_relocate<std::__1::allocator<int>, int>' requested here
  994 |   std::__uninitialized_allocator_relocate(
      |        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:1444:5: note: in instantiation of member function 'std::__1::vector<int>::__swap_out_circular_buffer' requested here
 1444 |     __swap_out_circular_buffer(__v);
      |     ^
/home/chuanqi.xcq/std_modules_testing/main.cpp:4:5: note: in instantiation of member function 'std::__1::vector<int>::reserve' requested here
    4 |   v.reserve(0);
      |     ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/iterator.h:23:29: note: 'iterator<std::__1::random_access_iterator_tag, int>' has been explicitly marked deprecated here
   23 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator {
      |                             ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:970:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
  970 | #    define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
      |                                         ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:943:49: note: expanded from macro '_LIBCPP_DEPRECATED'
  943 | #      define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
      |                                                 ^
1 warning generated.

And from the log I see the only location that makes isInSystemHeader return false is the location in the main.cpp. It is not related the modules. Or in another world, from the dumpped location, I see no locations in the std module.

So I am wondering if the change of patch itself is good but something bad happens in other places of the code path. But that patch triggers it.

I haven't found any logic in clang to handle system (standard) module.

Yes, there isn't such one. Since our previous consensus it try to avoid treating std modules special as much as possible.

For playing locally, you can use Decl::getOwningModule() to get the module. And use Module::getTopLevelModuleName() to get the module's name and judge if its name starts with std. It is not efficiency. But it should be good enough to test locally.

And I don't know there is a map from location to modules. But I feel it may not be an issue. Since we implement std module by including headers: https://github.com/llvm/llvm-project/blob/0ef61ed54dca2e974928c55b2144b57d4c4ff621/libcxx/modules/std.cppm.in#L14-L57 and the std.cppm itself is almost empty now. Maybe we can introduce something like #pragma clang system_modules in the future, but I think it should be fine now.

[ChuanqiXu9]

@cor3ntin gentle ping

[ChuanqiXu9]

BTW, @mordante do you think if this is a good example that we need more tests about import std;? I just noticed that this is brought into clang18 and I feel it may make people confusing...

(I know there are some practical issues in testing std module more in libc++. I just want to know if it is still on the plan)

[mordante]

I still like to have more libc++ tests using import std;. I have not really brought it up again with the libc++ developers. At the moment I'm quite busy with some other work in libc++ so this is a bit lower on my priority list.

[rnikander]

I've hit this too. Using import std was working okay until I upgraded Clang and got this.

It's made more painful because Emacs is highlighting some of the "In module 'std' imported" lines as errors, so I'd need to work on Emacs config if I want to be able to scroll through my build output for errors without being swamped with is stuff.

[ChuanqiXu9]

@cor3ntin may you take a look at this?

[cor3ntin]

@ChuanqiXu9 I am afraid i don't really have time to look at that at the moment (and it's unclear to me how to implement "isIsStdModule" for a given source location)

[ChuanqiXu9]

@ChuanqiXu9 Yes, I'm a bit confused, sorry. Can we agree that isInSystemHeader returns false for locations in the std module, and that this is wrong?

Yes, it should be wrong. But my confusion point is, I didn't see the isInSystemHeader return false for locations in the std module.

For example, if I insert the following code into aafad2d#diff-e32ebf7695e8361164e8f353f15548838d994990b08f29778bc6aced8f2ecb01R547

if (ShouldAllowWarningInSystemHeader) {
    llvm::errs() << "Instantiation Loc:";
    InstantiationLoc.print(llvm::errs(), S.getSourceManager());
    llvm::errs() << "\n";
  }

and compile the reproducer (https://godbolt.org/z/4rz4rehcz) locally, I'll see:

Instantiation Loc:/home/chuanqi.xcq/std_modules_testing/main.cpp:4:5
In module 'std' imported from /home/chuanqi.xcq/std_modules_testing/main.cpp:1:
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, int>' is deprecated [-Wdeprecated-declarations]
   53 |     : public iterator<typename iterator_traits<_Iter>::iterator_category,
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:531:40: note: in instantiation of template class 'std::__1::reverse_iterator<int *>' requested here
  531 |     std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_));
      |                                        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>::operator()' requested here
   86 |       __rollback_();
      |       ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>::~__exception_guard_exceptions' requested here
  137 |   return __exception_guard<_Rollback>(std::move(__rollback));
      |          ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:633:14: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>' requested here
  633 |         std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Tp*>(__alloc, __destruct_first, __result));
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:994:8: note: in instantiation of function template specialization 'std::__uninitialized_allocator_relocate<std::__1::allocator<int>, int>' requested here
  994 |   std::__uninitialized_allocator_relocate(
      |        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:1444:5: note: in instantiation of member function 'std::__1::vector<int>::__swap_out_circular_buffer' requested here
 1444 |     __swap_out_circular_buffer(__v);
      |     ^
/home/chuanqi.xcq/std_modules_testing/main.cpp:4:5: note: in instantiation of member function 'std::__1::vector<int>::reserve' requested here
    4 |   v.reserve(0);
      |     ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/iterator.h:23:29: note: 'iterator<std::__1::random_access_iterator_tag, int>' has been explicitly marked deprecated here
   23 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator {
      |                             ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:970:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
  970 | #    define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
      |                                         ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:943:49: note: expanded from macro '_LIBCPP_DEPRECATED'
  943 | #      define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
      |                                                 ^
1 warning generated.

And from the log I see the only location that makes isInSystemHeader return false is the location in the main.cpp. It is not related the modules. Or in another world, from the dumpped location, I see no locations in the std module.

So I am wondering if the change of patch itself is good but something bad happens in other places of the code path. But that patch triggers it.

I haven't found any logic in clang to handle system (standard) module.

Yes, there isn't such one. Since our previous consensus it try to avoid treating std modules special as much as possible.

For playing locally, you can use Decl::getOwningModule() to get the module. And use Module::getTopLevelModuleName() to get the module's name and judge if its name starts with std. It is not efficiency. But it should be good enough to test locally.

And I don't know there is a map from location to modules. But I feel it may not be an issue. Since we implement std module by including headers:

https://github.com/llvm/llvm-project/blob/0ef61ed54dca2e974928c55b2144b57d4c4ff621/libcxx/modules/std.cppm.in#L14-L57

and the std.cppm itself is almost empty now. Maybe we can introduce something like #pragma clang system_modules in the future, but I think it should be fine now.

@cor3ntin oh, I am not asking you to implement isStdModuleSourceLocation or anything. I want to say, the problem looks not related to isInSystemHeader doesn't work correctly. See my above comments, from my dumpped result, all the result from isInSystemHeader looks good. So I don't think we need to isStdModuleSourceLocation.

If you don't have time, how do you think about reverting https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890 temporarily?

[cor3ntin]

If you don't have time, how do you think about reverting https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890 temporarily?

I don't think this is a good option, we rely on this mechanism to display deprecation warnings in libc++. It would be nice to have a reduced reproducer (and I do not know how to reduce module code)

[ChuanqiXu9]

@cor3ntin I found a reproducer, but I am not sure if the base line is correct.

// RUN: rm -rf %t
// RUN: mkdir -p %t
// RUN: split-file %s %t
//
// Treat the behavior of using headers as baseline.
// RUN: %clang_cc1 -std=c++20 %t/use-header.cc -fsyntax-only -verify
//
// RUNX: %clang_cc1 -std=c++20 %t/a.cppm -emit-module-interface -o %t/a.pcm
// RUNX: %clang_cc1 -std=c++20 %t/use-module.cc -fmodule-file=a=%t/a.pcm -fsyntax-only -verify

//--- sys.h
#pragma clang system_header

template <class C>
struct [[deprecated]] iterator {};

template <class T>
class C {
public:
    void i() {
        iterator<T> i;
    }
};

//--- use-header.cc
// expected-no-diagnostics
// However, we see unexpected warnings
#include "sys.h"

void use() {
    C<int>().i();
}

//--- a.cppm
module;
#include "sys.h"
export module a;
export using ::iterator;
export using ::C;

//--- use-module.cc
// expected-no-diagnostics
import a;

void use() {
    C<int>().i();
}

Here I thought I got a reproducer. But I suddenly find the baseline of the reproducer (which only uses headers) will fail too. Is this behavior expected or not? @mordante

Then I am wondering the original reproducer, where the message shows the deprecated iterator is actually instantiated, then I am not sure where is the line to discard or not.

[mordante]

The only main difference I see is your header has no include guards and we use #pragma GCC system_header. I think these should not make a difference.

[cor3ntin]

The behavior of the warning in the header case is consistent with the intent of https://github.com/llvm/llvm-project/commit/aafad2d214246bae4d53ce3178b11486ebc83890

iterator<int> is instantiated from use(), which is in user code, therefore a warning is emitted. If libc++ folks think this is too aggressive, we need to refine the set of circumstances in which we emit depreciation warning for specializations. But that reproduction doesn't seem consistent with the bug initially reported.

[ChuanqiXu9]

Yeah, maybe we need to look at the instantiation trace at: https://godbolt.org/z/K94xYPhPG since it looks like the root of the instantiation started from user's code too. We need to make sure if the instantiation path different in modules and in headers mode. @mordante

[ChuanqiXu9]

Some update for this, I inserted

if (ShouldAllowWarningInSystemHeader) {
    llvm::errs() << "Loc:" << Loc.printToString(S.getSourceManager()) << "\n";
    llvm::errs() << "Expansioned Loc: " 
                 << S.getSourceManager().getExpansionLoc(Loc).printToString(S.getSourceManager())
                 << "\n";
    llvm::errs() << "Is it in system header: "
                 << S.getSourceManager().isInSystemHeader(S.getSourceManager().getExpansionLoc(Loc))
                 << "\n";
    llvm::errs() << "InstantiationLoc: "
                 << InstantiationLoc.printToString(S.getSourceManager())
                 << "\n";
    llvm::errs() << "Is instantiation in system header: "
                 << S.getSourceManager().isInSystemHeader(InstantiationLoc)
                 << "\n";
    ReferringDecl->dump();
  }

to https://github.com/llvm/llvm-project/blob/main/clang/lib/Sema/SemaAvailability.cpp#L547

and I tried to compile the following code with libc++

#include <vector>
int main() {
        std::vector<int> v;
        v.reserve(0);
}

And I see ShouldAllowWarningInSystemHeader turns to be true and I can see the instantiation location in the user's code. The code in https://github.com/llvm/llvm-project/blob/3785d7424680e0bcb914a485af61be51559ab1ba/clang/lib/Sema/SemaAvailability.cpp#L568 get executed too. I just don't get why it doesn't emit warnings actually.

I suspect it just works due to some surprising matches in diagnostic engines and it just didn't match with modules. I need to debug more.

@cor3ntin would you like to check it? I feel the original implementation has some problems which got covered by other places.

[ChuanqiXu9]

Now I located https://github.com/llvm/llvm-project/blob/a19a4113df3e9a3ca3747075da6de21901796524/clang/lib/Basic/DiagnosticIDs.cpp#L519-L523C7

with headers version, the value of Mapping.getSeverity() is Ignored and with modules versions, the value of Mapping.getSeverity() is Warning. In both version, the dumpped Loc is include/c++/v1/__iterator/reverse_iterator.h:53:14. So we can see DiagnosticsEngine::SuppressSystemWarnings didn't get involved here. Something heppens earlier masked the change of @cor3ntin 's patch. So, if I don't make a mistake, it is a false negative diagnostic for the reproducer in the header's version.

@mordante can you take a look at the instantiation path to make sure if it is fine or problematic actually?

Here is the path in my environment:

In module 'std' imported from /home/chuanqi.xcq/std_modules_testing/main.cpp:1:
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/reverse_iterator.h:53:14: warning: 'iterator<std::__1::random_access_iterator_tag, int>' is deprecated [-Wdeprecated-declarations]
   53 |     : public iterator<typename iterator_traits<_Iter>::iterator_category,
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:529:40: note: in instantiation of template class 'std::__1::reverse_iterator<int *>' requested here
  529 |     std::__allocator_destroy(__alloc_, std::reverse_iterator<_Iter>(__last_), std::reverse_iterator<_Iter>(__first_));
      |                                        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:86:7: note: in instantiation of member function 'std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>::operator()' requested here
   86 |       __rollback_();
      |       ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__utility/exception_guard.h:137:10: note: in instantiation of member function 'std::__exception_guard_exceptions<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>::~__exception_guard_exceptions' requested here
  137 |   return __exception_guard<_Rollback>(std::move(__rollback));
      |          ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__memory/uninitialized_algorithms.h:631:14: note: in instantiation of function template specialization 'std::__make_exception_guard<std::_AllocatorDestroyRangeReverse<std::__1::allocator<int>, int *>>' requested here
  631 |         std::__make_exception_guard(_AllocatorDestroyRangeReverse<_Alloc, _Tp*>(__alloc, __destruct_first, __result));
      |              ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:987:8: note: in instantiation of function template specialization 'std::__uninitialized_allocator_relocate<std::__1::allocator<int>, int>' requested here
  987 |   std::__uninitialized_allocator_relocate(
      |        ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/vector:1437:5: note: in instantiation of member function 'std::__1::vector<int>::__swap_out_circular_buffer' requested here
 1437 |     __swap_out_circular_buffer(__v);
      |     ^
/home/chuanqi.xcq/std_modules_testing/main.cpp:4:5: note: in instantiation of member function 'std::__1::vector<int>::reserve' requested here
    4 |   v.reserve(0);
      |     ^
Diagnosted.
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__iterator/iterator.h:23:29: note: 'iterator<std::__1::random_access_iterator_tag, int>' has been explicitly marked deprecated here
   23 | struct _LIBCPP_TEMPLATE_VIS _LIBCPP_DEPRECATED_IN_CXX17 iterator {
      |                             ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:969:41: note: expanded from macro '_LIBCPP_DEPRECATED_IN_CXX17'
  969 | #    define _LIBCPP_DEPRECATED_IN_CXX17 _LIBCPP_DEPRECATED
      |                                         ^
/home/chuanqi.xcq/llvm-project-for-work/build_libcxx/include/c++/v1/__config:934:49: note: expanded from macro '_LIBCPP_DEPRECATED'
  934 | #      define _LIBCPP_DEPRECATED __attribute__((__deprecated__))
      |

[ChuanqiXu9]

Oh, I finally got a reproducer:

// RUN: rm -rf %t
// RUN: mkdir -p %t
// RUN: split-file %s %t
//
// Treat the behavior of using headers as baseline.
// RUN: %clang_cc1 -std=c++20 %t/use-header.cc -isystem %t -fsyntax-only -verify
//
// RUN: %clang_cc1 -std=c++20 %t/a.cppm -isystem %t -emit-module-interface -o %t/a.pcm
// RUN: %clang_cc1 -std=c++20 %t/use-module.cc -isystem %t -fmodule-file=a=%t/a.pcm -fsyntax-only -verify

//--- reverse_iterator.h
#ifndef REVERSE_ITERATOR_H
#define REVERSE_ITERATOR_H

#pragma GCC system_header

template <class C>
struct [[deprecated]] iterator {};

_Pragma("GCC diagnostic push")
_Pragma("GCC diagnostic ignored \"-Wdeprecated\"")                         
_Pragma("GCC diagnostic ignored \"-Wdeprecated-declarations\"")

template <class C>
struct reverse_iterator 
#if !defined(_LIBCPP_ABI_NO_ITERATOR_BASES)
: public iterator<C> {};

#endif

_Pragma("GCC diagnostic pop")

#endif

//--- sys.h
#ifndef SYS_H
#define SYS_H

#include <reverse_iterator.h>

#pragma GCC system_header

template <class T>
class C {
public:
    void i() {
        reverse_iterator<T> i;
    }
};

#endif SYS_H

//--- use-header.cc
// expected-no-diagnostics
// However, we see unexpected warnings
#include <sys.h>

void use() {
    C<int>().i();
}

//--- a.cppm
module;
#include <sys.h>
export module a;
export using ::iterator;
export using ::C;

//--- use-module.cc
// expected-no-diagnostics
import a;

void use() {
    C<int>().i();
}

then the behavior of libc++ should be fine. It is the fault of clang didn't handle these _Pragma well. Yeah, I still think the behavior of https://github.com/llvm/llvm-project/blob/bf57d2e57c3e708a32c1f8a273b0e3465078d7b5/clang/lib/Sema/SemaAvailability.cpp#L543-L554 is somewhat not perfect but this doesn't matter for this issue now.

[ChuanqiXu9]

Oh, this turns out to be some "optimization" I did before, which get revealed by the above change. I'll fix this quickly. Sorry for wasting your time : (

[cor3ntin]

@ChuanqiXu9 Sorry I wasn't of more help (modules confuse me)! Thanks for working on it

[mpusz]

I got the same error while doing import std; on the latest clang-18 + libc++-18 from APT.

[ChuanqiXu9]

Oh, sorry for that. But according to the release plan (https://discourse.llvm.org/t/18-1-8-released/79725), there won't be more 18.x releases unless critical issues found (I don't think this one is critical).

Can you verify if the newest compiler in trunk can fix your issue?

[mpusz]

Unfortunately, libc++-19 seems not to provide libc++.modules.json so I am not using it for modules testing 😢

[ChuanqiXu9]

Unfortunately, libc++-19 seems not to provide libc++.modules.json so I am not using it for modules testing 😢

Oh, this is surprising and not expected to me. Do you know the reason?

CC: @mordante @ldionne

[mpusz]

When I check which apt repositories contain that file, this is what I get:

$ sudo apt-file search libc++.modules.json
libc++-18-dev: /usr/lib/llvm-18/lib/libc++.modules.json

and I have:

$ cat /etc/apt/sources.list.d/archive_uri-http_apt_llvm_org_noble_-noble.list 
deb http://apt.llvm.org/noble/ llvm-toolchain-noble-16 main
# deb-src http://apt.llvm.org/noble/ llvm-toolchain-noble-16 main
deb http://apt.llvm.org/noble/ llvm-toolchain-noble-17 main
# deb-src http://apt.llvm.org/noble/ llvm-toolchain-noble-17 main
deb http://apt.llvm.org/noble/ llvm-toolchain-noble-18 main
# deb-src http://apt.llvm.org/noble/ llvm-toolchain-noble-18 main
deb http://apt.llvm.org/noble/ llvm-toolchain-noble main
# deb-src http://apt.llvm.org/noble/ llvm-toolchain-noble main

[ldionne]

I don't think we changed anything on our side. Unfortunately, we don't control the APT packages and lately they seem to have been rather broken. We should perhaps look into integrating the production of these packages into the monorepo so we can have control over them.

[mpusz]

Yeah, the missing header file for libc++-18 is solved but we have a new one now:

error while loading shared libraries: libc++.so.1: cannot open shared object file: No such file or directory

https://github.com/mpusz/mp-units/actions/runs/9930500562/job/27508441029

:-(

[ChuanqiXu9]

@mpusz Given nothing changed in libc++'s side, I am guessing if APT's packagers use a different configuration when building packages on trunk with the formal release packages. Otherwise, maybe they are only disabled installing modules (why?). I think we have to reach out APT's packages in both cases.

[mordante]

@mpusz Given nothing changed in libc++'s side, I am guessing if APT's packagers use a different configuration when building packages on trunk with the formal release packages. Otherwise, maybe they are only disabled installing modules (why?). I think we have to reach out APT's packages in both cases.

See https://github.com/llvm/llvm-project/issues/99017 the apt packager is looking at it.

[ChuanqiXu9]

@mpusz Given nothing changed in libc++'s side, I am guessing if APT's packagers use a different configuration when building packages on trunk with the formal release packages. Otherwise, maybe they are only disabled installing modules (why?). I think we have to reach out APT's packages in both cases.

See #99017 the apt packager is looking at it.

@mordante there is another issue. Why libc++.modules.json is missing in libc++-19? Should we reach out the packagers for the issue too?

[mordante]

@mpusz Given nothing changed in libc++'s side, I am guessing if APT's packagers use a different configuration when building packages on trunk with the formal release packages. Otherwise, maybe they are only disabled installing modules (why?). I think we have to reach out APT's packages in both cases.

See #99017 the apt packager is looking at it.

@mordante there is another issue. Why libc++.modules.json is missing in libc++-19? Should we reach out the packagers for the issue too?

That file used to be shipped in the apt packages. There were some changes in the APT packaging so this might be the same issue. Let's verify when the packages are working again whether libc++.modules.json is present again.

[ChuanqiXu9]

@mpusz Given nothing changed in libc++'s side, I am guessing if APT's packagers use a different configuration when building packages on trunk with the formal release packages. Otherwise, maybe they are only disabled installing modules (why?). I think we have to reach out APT's packages in both cases.

See #99017 the apt packager is looking at it.

@mordante there is another issue. Why libc++.modules.json is missing in libc++-19? Should we reach out the packagers for the issue too?

That file used to be shipped in the apt packages. There were some changes in the APT packaging so this might be the same issue. Let's verify when the packages are working again whether libc++.modules.json is present again.

OK. I am not sure since https://github.com/llvm/llvm-project/issues/99017 is about libc++-18 but we're discussing libc++-19. But given 19.x will be formally released in September, we have enough time.

[mordante]

I checked the libc++-19-dev_19 dev package and it contains the ./usr/lib/llvm-19/lib/libc++.modules.json.