There's many instances in clang tidy checks where owning strings are used when we already have a stable string from the options, so using a StringRef makes much more sense.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I went through the changes and they look correct to me... yet I'm still mildly terrified. :-D Have you tried running clang-tidy through its paces with ASan/MSan enabled to see if the change introduces any use-after-free issues in practice?
I can't seem to build LLVM with msan at all. But ASan, which checks things like use after free, ran all clang tools tests without a hitch.
clang-tools-extra/clang-tidy/ClangTidyCheck.cpp | ||
---|---|---|
51 | Why is StringRef::operator+ considered "better" than std::string::operator+? | |
56 | find takes a StringRef so why convert to std::string here? | |
123 | operator[] takes a StringRef so why convert to std::string here? | |
clang-tools-extra/clang-tidy/ClangTidyCheck.h | ||
158 | I think I would feel safer if the changes to the infrastructure were pushed separately from the changes to the checks, with some "bake time" in between so we have more confidence in the changes. While debugging my own checks, I've seen that there are surprises with the lifetimes of StringRef. |
clang-tools-extra/clang-tidy/ClangTidyCheck.cpp | ||
---|---|---|
51 | Because 2 strings are created in the second instance, whereas only one is created in the first. | |
56 | Because a concatenation of StringRef results in a Twine, which cannot be passed to find. | |
123 | Again can't use a Twine for operator[]. | |
clang-tools-extra/clang-tidy/ClangTidyCheck.h | ||
158 | These changes on their own don't make any sense without the corresponding changes to the checks. |
Thanks for checking! I've convinced myself that I don't see any lifetime issues here (in each case, what the StringRef refers to should outlive the StringRef), so this LGTM.
Hi,
I noticed that this patch isn't NFC.
If I run
clang-tidy -checks='*' empty.c --
on an empty file empty.c I get the following printouts with this patch:
'addr=address' 'arr=array' 'attr=attribute' 'buf=buffer' 'cl=client' 'cnt=count' 'col=column' 'cpy=copy' 'dest=destination' 'dist=distancedst=distance' 'elem=element' 'hght=height' 'i=index' 'idx=index' 'len=length' 'ln=line' 'lst=list' 'nr=number' 'num=number' 'pos=position' 'ptr=pointer' 'ref=reference' 'src=source' 'srv=server' 'stmt=statement' 'str=string' 'val=value' 'var=variable' 'vec=vector' 'wdth=width'
but without this patch it's completely silent.
clang-tools-extra/clang-tidy/ClangTidyCheck.cpp | ||
---|---|---|
56 | Interactions between std::string, StringRef and Twine always make my brain hurt :). I keep wondering if there's a way to make StringRef and Twine more user-friendly, or perhaps a clang-tidy check that will alert you to things that are "considered harmful". |
I think I would feel safer if the changes to the infrastructure were pushed separately from the changes to the checks, with some "bake time" in between so we have more confidence in the changes.
While debugging my own checks, I've seen that there are surprises with the lifetimes of StringRef.