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

Zachary Turner via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 5 09:59:04 PDT 2016


zturner added a comment.

I guess my comment applies everywhere there is a call to `.data()`.  Suppose you shelve this CL, then go change some of the places where you are using `.data()` in this CL to accept `StringRef` arguments, then rebase this CL on top of those.  Since those functions have been left alone in this CL, I would guess that many of them are independent of the changes in this CL and could be converted to `StringRef` first (and in much smaller CLs), then when you come back to this one you won't have to use `.data()` so much.

As mentioned in the first comment though, whenever `.data()` is necessary, I would tend to favor `.str().c_str()`  (the fact that it is inefficient compared to `.data()` could serve as more incentive to go fix the other places first so that you don't have to do either one)



> Compilation.cpp:105
>           it = Files.begin(), ie = Files.end(); it != ie; ++it)
> -    Success &= CleanupFile(*it, IssueErrors);
> +    Success &= CleanupFile(it->data(), IssueErrors);
>    return Success;

In general, I prefer `it->str().c_str()` over `data()` almost everywhere.  Yes it's slower, but we shouldn't be making any assumptions about the underlying `StringRef`.  And anyway, in this particular case we're dealing with the filesystem.  An extra alloc isn't goign to hurt.

> Driver.cpp:618
>        OS << ' ';
> -    Command::printArg(OS, *I, true);
> +    Command::printArg(OS, I->data(), true);
>    }

Can you change `Command::printArg` to take a `StringRef`?  If it's too hard to change it outright, you could add an overload.

> Driver.cpp:796
>    std::string TmpName = GetTemporaryPath("response", "txt");
> -  Cmd.setResponseFile(
> -      C.addTempFile(C.getArgs().MakeArgString(TmpName.c_str())));
> +  Cmd.setResponseFile(C.addTempFile(C.getArgs().MakeArgString(TmpName)).data());
>  }

Can `setResponseFile` take a `StringRef`?

> Driver.cpp:1168
>      for (unsigned i = 0, e = Archs.size(); i != e; ++i)
> -      Inputs.push_back(C.MakeAction<BindArchAction>(Act, Archs[i]));
> +      Inputs.push_back(C.MakeAction<BindArchAction>(Act, Archs[i].data()));
>  

Can `BindArchAction` take a `StringRef`?

> Driver.cpp:1310
> +          if (ExtIdx != StringRef::npos)
> +            Ty = TC.LookupTypeForExtension(Value.data() + ExtIdx + 1);
>  

Can `LookupTypeForExtension` take a `StringRef`?

> Driver.cpp:1350
> +            const char *Ext = Value.data() + ExtIdx + 1;
> +            if (TC.LookupTypeForExtension(Ext) == types::TY_Object)
> +              Ty = types::TY_Object;

Same as above.

> Driver.cpp:2314
>                         /*MultipleArchs*/ ArchNames.size() > 1,
> -                       /*LinkingOutput*/ LinkingOutput, CachedResults,
> +                       /*LinkingOutput*/ LinkingOutput.data(), CachedResults,
>                         /*BuildForOffloadDevice*/ false);

Same here.

https://reviews.llvm.org/D25257





More information about the llvm-commits mailing list