aaron.ballman closed this revision.
aaron.ballman added a comment.
Commit in r273599.
http://reviews.llvm.org/D21643
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
aaron.ballman added a comment.
In http://reviews.llvm.org/D21643#465583, @llvm-commits wrote:
> Should we add overloads of the UTF8 conversion functions that accept
> wstrings?
I think we should eventually consider cleaning up our Unicode APIs because
they're kind of all over the place. For i
rnk added a comment.
In http://reviews.llvm.org/D21643#465584, @aaron.ballman wrote:
> I have never successfully built compiler-rt with MSVC. Every time I've tried
> (the last time was 6+ months ago, so I will try again), the MSVC solution
> generated by CMake refuses to compile. From what I un
aaron.ballman added a comment.
In http://reviews.llvm.org/D21643#465579, @rnk wrote:
> Sure, this serves as a reminder that you should always convert from UTF-8 to
> wide in Windows support code. I still think we should always explicitly call
> the wide variants, and it seems like you agree. De
Should we add overloads of the UTF8 conversion functions that accept
wstrings?
In line with what rnk said, I'm curious about the implications of simply
#undef'ing all the non A/W versions of functions so that you have to make
the choice explicit
On Thu, Jun 23, 2016 at 8:20 AM Reid Kleckner wrote
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.
Sure, this serves as a reminder that you should always convert from UTF-8 to
wide in Windows support code. I still think we should always explicitly call
the wide variants, and it seems like you agr
aaron.ballman created this revision.
aaron.ballman added reviewers: rnk, majnemer, chapuni, zturner.
aaron.ballman added subscribers: llvm-commits, cfe-commits.
We currently default to using the multibyte character versions of Win32 APIs,
commonly suffixed with an "A". However, this causes proble
