Add mapping generator for libstdc++ #1606
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
also cc @justanotheranonymoususer if you're interested in an example of generated mappings |
Informational: IWYU dogfood resultsinclude-what-you-use (exit: 0)fix_includes.py (exit: 0)diff |
|
I don't know python enough for reviewing this. The changes to the mappings seem reasonable. |
|
I don't know python either, but more fundamental I don't understand how the library detects automatically the mappings from the lib std++ code alone. What is the advantage of maintaining the python script vs the mappings themselves? |
It's possible to see some patterns in the library code, which lets you tell the difference between public and private headers (this is described in detail in the script doc comments). Armed with that knowledge, you can say that an include from a public header to a private header implies a mapping from public to private. There are exceptions and special cases, and they are also encoded in the script.
See PR description, but yes, pretty much. The mappings were originally generated by shell pipelines for GCC 4.6, then manually edited, then manually patched as issues were found. At this point the set of mappings on master is basically unmaintainable when faced with a new GCC version. |
Interesting, are those patterns general or only applicable to libstdc++? Also, I found that concrete mappings for libstd++ (GNU) and libc++ (LLVM) are very different, for that matter.
I see. Also, would this cover the cases for libc++? |
No, those exact patterns are only relevant for libstdc++. Other libraries have other patterns, as encoded in the other mapgen scripts.
Yeah, libc++ is a different library with different conventions.
I was just thinking about that the other day. Assuming the patterns hold across GCC versions, it should be possible to install and generate mappings for every major GCC version, then keep version-keyed maps in |
kimgr
force-pushed
the
libstdcxx-mapgen
branch
from
d8ecbf0 to
02159c3
Compare
|
The build failure looks like this: llvm/llvm-project#99819 |
kimgr
force-pushed
the
libstdcxx-mapgen
branch
from
ae408a1 to
0f021a1
Compare
|
@firewave Thanks, yeah, I started trying to work around it, but there were many different files missing. It would be nice if CMake could be convinced to ignore missing files (or convert the error to a warning); very few of these errors are actually relevant to us. |
There is unfortunately a lack of documentation for the CMake integration. But I had a quick look at the file and it doesn't seem like any of this might be configurable. It also references CMake 2.8 so it seems like this stuff hasn't been touched in ages. |
This replaces the built-in libstdc++ mappings with a machine-generated set. Since debug headers are also part of the generated corpus, remove the special debug header mapping table. Replace gcc.stl.headers.imp with generated mappings, and remove the now-obsolete gcc.stl.debug.imp.
Mostly to have the built-in mapping generator procedure and tradeoffs documented.
kimgr
force-pushed
the
libstdcxx-mapgen
branch
from
0f021a1 to
d39077f
Compare
Informational: IWYU dogfood resultsinclude-what-you-use (exit: 0)fix_includes.py (exit: 0)diff |
|
OK, I'm going to say this is ready for action now. Yolo, etc! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If this seems to work out, the procedure for updating mappings should be:
followed by some cutting and pasting to get the right lines into the right place (this can obviously be improved over time).
Poor mappings can now be improved in the python code instead of manually in the mapping tables, which makes tracking much easier.
And above all, users running a very new or very old GCC can simply regenerate their mappings in situ and use a generated
.imptable or patch their IWYU source and rebuild with matching builtin mappings.@firewave @alejandro-colomar @correaa Let me know what you think.