alexfh added a comment.
May I ask you to upload patches with full diff context next time? I know, it's
not directly supported by TortoiseGit, but there are at least two other
reasonable ways of generating full diffs for Phabricator:
http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
and
http://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-command-line.
Wrt testing, I think, apart from a new clang-tidy test, the changes to Driver
and Tooling need separate tests as well.
================
Comment at: lib/Tooling/JSONCompilationDatabase.cpp:119
@@ -115,1 +118,3 @@
StringRef EscapedCommandLine) {
+#if defined(LLVM_ON_WIN32)
+ llvm::BumpPtrAllocator Alloc;
----------------
zturner wrote:
> rnk wrote:
> > It would be nice if the JSON file just told us which quoting mechanism it
> > was using. You can imagine building the compilation database on one system
> > and sending it off to another for indexing.
> Correct me if I've got this wrong but:
>
> 1. If you had a compile command database generated on non-Windows, and you
> used it on Windows, then it would necessarily be referring to something other
> than clang-cl right? In which case, we don't support running clang in non-cl
> mode on Windows.
>
> 2. If you had a compile command database generated on Windows, then the only
> supported configuration would involve clang-cl, in which case you couldn't
> use it on non-Windows.
>
> Is there a supported use case where a non-Windows compile database would be
> used on Windows or vice versa?
> we don't support running clang in non-cl mode on Windows.
I think, clang in non-cl mode is functional on Windows to a certain degree
(mingw-compatibility or something like this). Artificially preventing it from
working doesn't seem to be right.
https://reviews.llvm.org/D23409
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
