On Tue, Feb 26, 2019 at 1:06 PM Gabriel Dos Reis via Modules <
modules_at_[hidden]> wrote:

> I believe the plan is to have Windows and Visual C++ support useful UTF-8
> pathnames. I can’t say anything about release dates, etc. But, please do
> keep Roy (in CC:) and myself informed of any related issues you run into.
>
> — Gaby
>

UTF-8, or WTF-8 (https://simonsapin.github.io/wtf-8/)?

Only WTF-8 will accept all valid NTFS paths.

- Michael Spencer


>
> On Feb 26, 2019, at 3:30 AM, Steve Downey <sdowney_at_[hidden]> wrote:
>
> I'm pretty sure compilation DB totally ignores this, and is easy to get
> invalid json in. Makefile syntax would care somewhat less.
>
> I don't think it would be the worst thing for these tools to require
> Unicode without any normalization. You have to be able to fopen, and that
> means an exact match. I don't know the state of the world for Windows for
> utf-8 vs ucs2. Can we reliably get the file open?
>
> I think the TR can place more requirements than the IS can on file names.
>
> On Tue, Feb 26, 2019, 04:50 Manuel Klimek <klimek_at_[hidden]> wrote:
>
>> On Tue, Feb 26, 2019 at 4:01 AM Ben Boeckel <ben.boeckel_at_[hidden]>
>> wrote:
>>
>>> On Mon, Feb 25, 2019 at 09:52:34 +0100, Manuel Klimek wrote:
>>> > In the compilation database (
>>> > https://clang.llvm.org/docs/JSONCompilationDatabase.html
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fclang.llvm.org%2Fdocs%2FJSONCompilationDatabase.html&data=02%7C01%7Cgdr%40microsoft.com%7C1713ebab01f64789483f08d69bee9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636867846488500443&sdata=CorqQwp20HXVHjavBly%2Brq3gpElInvQDftma%2Fe%2BYnzI%3D&reserved=0>)
>>> we specify the
>>> > build dir for each file.
>>>
>>> But that is (generally) output from the build system, not the compiler.
>>> The build system knows because…well, it does. The compiler is just
>>> invoked in a working directory and given no indication of where a "root"
>>> directory is (and I think it might be silly to pass it on the command
>>> line just to have it in this file, but maybe not).
>>
>>
>> Can't the compiler put in the current work directory it's been called
>> with? That's what I'd expect.
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C1713ebab01f64789483f08d69bee9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636867846488510838&sdata=DtIbuyEnipgahSMOZOOfQzhERDx9s%2FoOsXSRnqPUloc%3D&reserved=0>
>>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C1713ebab01f64789483f08d69bee9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636867846488520853&amp;sdata=wDbeZoFkUTvGKDYVi9HowzdlN7LCuFQEZ8Cq9pX0dHE%3D&amp;reserved=0
> Link to this post:
> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F02%2F0105.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7C1713ebab01f64789483f08d69bee9d5b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636867846488530462&amp;sdata=VugT4VetiLu1ndkQWi0hYv1lFXMDWxPPT67Ou%2FF6cCE%3D&amp;reserved=0
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/02/0110.php
>