-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move charconv tables #2125
Move charconv tables #2125
Conversation
…into charconv_tables
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, this looks great! I've carefully verified that all of the code movement is preserving the tables and changing only necessary things. I've also verified that mixing TUs calling to_chars()
that have been compiled with main
and this PR results in successful linking, so I don't believe that we need to rename the individual tables (renaming the specialized struct is good and minimally invasive).
I've also verified that the generators continue to compile. They don't generate exactly what's in the headers now, but the transformations are obvious, and I would definitely prefer to avoid mixing the code movement here with any nontrivial updates to the generators.
I will validate and push changes for the minor issues I noticed.
This comment was marked as resolved.
This comment was marked as resolved.
I'm speculatively mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
I've had to push an additional commit to work around VSO-1579484 "Standard Library Header Units: charconv refactoring + topo sort = error LNK2019: unresolved external symbol". |
I've pushed changes to remove the I've also pushed a workaround change, suggested by @cdacamar, which avoids the need to modify the |
Thanks for this significant throughput improvement - it should substantially reduce the size of the Standard Library Header Units and Modules too! 😻 🚀 🎉 |
Co-authored-by: Stephan T. Lavavej <stl@microsoft.com>
Resolve #172
Resolve #2347