[PATCH] D122766: [clang] Use forward slash as the path separator for Windows in __FILE__, __builtin_FILE(), and std::source_location

Nico Weber via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Apr 6 10:23:52 PDT 2022

thakis added a comment.

Normalizing to `\` seems better to me than normalizing to `/` too.

I abstractly like changing as little as necessary at every stage, which in this case would mean changing just the slashiness of slashes that clang itself adds, so I'm still weakly in favor of that. But I also won't insist on it.

In D122766#3431468 <https://reviews.llvm.org/D122766#3431468>, @dexonsmith wrote:

> In D122766#3429552 <https://reviews.llvm.org/D122766#3429552>, @hans wrote:
>>> My feeling is that the default behavior on Windows needs to be to use backslashes and not forward slashes.
>> Okay, how would folks feel about always canonicalizing `__FILE__` etc. to use //backslashes// when targeting Windows?
> FWIW (I have little Windows experience and no stake in this!), defaulting to backslashes more sense to me. Also seems easy enough to add a preprocessor option to configure this.
> I'm curious though, if you're building on POSIX (so the file starts out as POSIX) and targeting Windows, does calling `make_preferred()` actually give you something reasonable in the general case? Or should it be used *only* when there's a hit in `LangOpts.remapPathPrefix()`? Sorry if this has been discussed and rejected; I haven't followed the full thread; feel free to ignore if it's not relevant; but it seems to me that when `-ffile-prefix-map` is NOT being used, then `__FILE__` ought to correspond to the build environment (if anything, it should use `Style::native`).

(We don't use `-ffile-prefix-map`. As https://blog.llvm.org/2019/11/deterministic-builds-with-clang-and-lld.html explains, using it means your commandlines *must* be machine-dependent, which we don't want. So we use `-ffile-compilation-dir=.` instead which has the same effect but doesn't have that drawback.)

  rG LLVM Github Monorepo



More information about the cfe-commits mailing list