libc++ should ship an IWYU mapping file

[cjdb]

After running IWYU on some ChromeOS third-party packages, I've observed that it pulls in a lot of the implementation headers instead of the standard ones. This can be fixed either by IWYU mapping every standard library symbol in their default mapping file, or by libc++ shipping its own header mapping file. While the former would be nice, it doesn't scale particularly well (my understanding is that you'd need to account for all the nested and semi-private symbols too), and is much more error-prone.

libc++'s Python tooling should be able to account for this, and it would probably go a long way to helping with the header migration that you're hoping to see in the future.

[JoeLoser]

I'd love to see this worked on. It's not ideal to maintain libc++ mappings internally outside of IWYU in a codebase for example as it quickly gets out-of-date with the modularization that's been happening recently in libc++, nor is it the right place first and foremost.

IIRC, clangd had some notion at one point of some libc++ mapping files - it would be awesome if both clangd and libc++ could have a single source of truth for these mapping files.

[kadircet]

yes that would be great. clangd (and rest of tooling) uses a mapping file derived from cppreference today because there are no first-hand mappings.

[cjdb]

I think it would be best if libc++ owned this because some of the URLs from cppreference are incorrectly named (namely the concepts).

It also gives libc++ the opportunity to flag certain headers as implementation details.