Clang-tidy pass detecting the use of const std::string& references.
Use of llvm::StringRef is recommended in the LLVM Programmer's Manual instead:
https://llvm.org/docs/ProgrammersManual.html#the-stringref-class
Differential D88314
Added llvm-string-referencing check bogser01 on Sep 25 2020, 9:09 AM. Authored by
Details
Clang-tidy pass detecting the use of const std::string& references. Use of llvm::StringRef is recommended in the LLVM Programmer's Manual instead:
Diff Detail
Event TimelineComment Actions Thank you for working on this check! Have you run the check over LLVM to see how much it reports? One of the concerns I have with this is that it's not always appropriate to replace a const std::string& with an llvm::StringRef and so I'm wondering what the "false positive" rate is for the check. For instance, there are std::string member functions that don't exist on StringRef so the fix-it will introduce compile errors, or switching the parameter type will cause additional unnecessary conversions.
Comment Actions It looks like you generated a diff from a previous diff instead of trunk -- can you regenerate the diff against trunk so that reviewers can see the full content of the changes? Comment Actions @aaron.ballman Thank you for picking up this review! Running the check over the entire LLVM causes ~74K warnings across 430 files. As to the false positive rate it's tricky to measure. Based on previous analysis on flang codebase, I would say roughly 50% of the fixes would cause compiler errors when applied. Comment Actions Woof, that's a pretty high false-positive rate for the check -- I don't think we should issue a fix-it for this case because anyone who accidentally applies fixits automatically will be in for a fair amount of pain. I'm a bit worried that the number of diagnostics this produces will basically mean the check has to be turned off for the only project that would use it. What is the expected use case for the check? For instance, are you expecting to craft a .clang-tidy file to disable this check on source files in the repo that are known to have a lot of diagnostics (so that the check mostly only fires for known-good files and new files)?
|
Looks like there are some accidental merge markers in the patch.