hokein added inline comments.
================ Comment at: clang/include/clang/Tooling/Inclusions/StdAlternativeHeaderMap.inc:3 +// +// This is a hand-curated list for C++ symbols (e.g. provided by multiple +// headers), to address the short comings of cppreference or automated ---------------- kadircet wrote: > hokein wrote: > > kadircet wrote: > > > `This is a hand-curated list for C++ symbols` reads like we're planning > > > to put all special C++ symbols into this file, rather than just the ones > > > that are provided by alternative headers. that's the reason why i > > > mentioned it as `This is a hand-curated list for symbols provided by > > > multiple headers` specifically. > > Restricting the file only to multiple-header symbols seems a bit narrow > > (and the `consume_header` symbol only has one header which doesn't fit into > > this bucket nicely). > > > > My take of this file is - we'll put all special C++ symbols that are not > > able to handle by the cppreference generator, multiple-header symbols are > > the most critical ones. > > > > What do you think? > > > > > > > > (and the consume_header symbol only has one header which doesn't fit into > > this bucket nicely). > > Well, i'd say they deserve their own list in that case. > > > > My take of this file is - we'll put all special C++ symbols that are not > > able to handle by the cppreference generator, multiple-header symbols are > > the most critical ones. > > I am afraid of that list getting too long and impossible to read manually any > more. > but since these are going to be private files soon, we can always do that > split once that's actually the case. > > We need a different name for this file in that case though. As I thought we > are only putting symbols with alternative headers into this file. What about > `StdSpecialSymbolMap.inc` instead and update the file comment to: > ``` > This is a hand-curated list for C++ symbols that cannot be parsed/extracted > via include-mapping tool. > ``` > > and not talk about `All headers for a symbol name provide the same > declaration (hence these are not overloads/variants like std::remove from > algorithm vs cstdio).` as we're planning to add them to here as well. it's > just we aren't adding them "right now". Yeah, this sounds good to me. > Well, i'd say they deserve their own list in that case. Yeah, this is an alternative (a mono file vs. muti files). I would start with a single file. The list of these symbols is not that large now. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D143160/new/ https://reviews.llvm.org/D143160 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
