kadircet 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
----------------
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".


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

Reply via email to