This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy][NFC] Replace many instances of std::string where a StringRef would suffice.
ClosedPublic

Authored by njames93 on Apr 24 2022, 1:42 AM.

Details

Summary

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.

Diff Detail

Event Timeline

njames93 created this revision.Apr 24 2022, 1:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2022, 1:42 AM
njames93 requested review of this revision.Apr 24 2022, 1:42 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 24 2022, 1:42 AM
Herald added a subscriber: cfe-commits. · View Herald Transcript
njames93 edited the summary of this revision. (Show Details)

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 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.

njames93 marked 4 inline comments as done.May 4 2022, 2:30 AM
njames93 added inline comments.
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.
Also the lifetime of all the checks options is tied to the ClangTidyOptions which outlives the checks.

aaron.ballman accepted this revision.May 4 2022, 4:03 AM

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.

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.

This revision is now accepted and ready to land.May 4 2022, 4:03 AM

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.

Hi,

I noticed that this patch isn't NFC.

Whoops, good catch. I left in some debugging code, fixed in rGa308a55720249749

Hi,

I noticed that this patch isn't NFC.

Whoops, good catch. I left in some debugging code, fixed in rGa308a55720249749

Thanks!

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".