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.
[libc++][print] Adds ostream overloads. #73262
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
[libc++][print] Adds ostream overloads. #73262
Changes from all commits
8e45740
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
In a follow-up, we could use
_LIBCPP_AVAILABILITY_HAS_PRINT
to check whether we have__get_ostream_file
on the current deployment target. If we don't, we could instead assume that!__file
and use__vprint_nonunicode
. That would make this mostly work for older deployment targets, except for theflush
below. But by and far, users could use<print>
on older deployment targets with no issues.We could then even remove the availability annotations on
__vprint_unicode
and others, since they would basically have no deployment target requirements anymore.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.
Created #75225 for this.
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.
Is there a reason why we have both
_LIBCPP_HAS_NO_UNICODE
and__print::__use_unicode
?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.
_LIBCPP_HAS_NO_UNICODE
means there platform has no unicode at all.__use_unicode
means the execution charset is not capable of Unicode. Currently this is only used with MSVC. There were (are?) plans to implement this in Clang too.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.
I would suggest renaming this to something like
__print::__unicode_execution_charset
, which IMO would make this somewhat clearer. I am OK if you want to do this in a separate NFC patch.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.
See #76290