[PATCH] D25257: Use StringRef in Option library instead of raw pointers (NFC)

[Reid Kleckner via llvm-commits]

rnk added a comment.

hm, this comment has been sitting unsubmitted for a while.



================
Comment at: clang/lib/Driver/Driver.cpp:97
+  for (StringRef Arg : Args) {
     // Ingore nullptrs, they are response file's EOL markers
+    if (Arg.empty())
----------------
mehdi_amini wrote:
> mehdi_amini wrote:
> > rnk wrote:
> > > Hang on, nullptr is different from an empty string in the response file parsing logic. We have to be careful not to affect that.
> > Good to know, during a recent discussion about StringRef we were wondering about examples where we'd like to differentiate between empty and null.
> > 
> > It seems we don't have any test that rely on this different right now, and I don't know about the "response file" (what are they, how to use them), I so don't feel I can come up easily with a test without guidance.
> @rnk ping
We mark EOLs in the response file mostly so that we can be compatible with MSVC, which has arguments that consume everything following them. Given this response file, the compilation command should get all the -D flags, and the link should get 3 -debug flags:
```
$ cat foo.rsp
-DFOO -link -debug
-DBAR -link -debug
-DBAZ -link -debug

$ clang-cl t.cpp @foo.rsp -###
...
"clang-cl" "-cc1" ... "-D" "FOO" "-D" "BAR" "-D" "BAZ"  ...
"link.exe" "-out:t.exe" "-nologo" "-debug" "-debug" "-debug" ...
```

So, we need a way to distinguish between empty strings and EOLs.

I mentioned one way to do this:
> Probably the right way to do this is to have a second optional output vector that has the indices of all the response file line endings.


https://reviews.llvm.org/D25257