This is an archive of the discontinued LLVM Phabricator instance.

[ADT] Delete Twine constructors which accept StringRef rvalues (NFC)
Needs RevisionPublic

Authored by vsk on Nov 11 2016, 3:43 PM.

Details

Summary

Twine stores a *pointer to a StringRef*, not a StringRef. Taking the address of a StringRef rvalue could easily give us a dangling pointer.

Adrian ran into this issue in the wild (see r286640). Deleting these constructors was his idea.

llvm/clang are teeming with Twine abuse, so landing this patch right now would break all of our builds. If this patch looks OK, I can start weeding out the issues.

Diff Detail

Event Timeline

vsk updated this revision to Diff 77685.Nov 11 2016, 3:43 PM
vsk updated this revision to Diff 77687.
vsk retitled this revision from to [ADT] Delete Twine constructors which accept StringRef rvalues (NFC).
vsk updated this object.
vsk added reviewers: aprantl, dblaikie.
vsk added a subscriber: llvm-commits.
  • Upload a diff with context.

Hm, this doesn't seem workable. Deleting these constructors would make it harder to pass strings into functions.

Maybe it would be better to try something like r286139, and just delete Twine &operator=(T &&) when T is a std::string or a StringRef. @jordan_rose wdyt?

I'm inclined to agree with @dblaikie's email comment: assigning a Twine is pretty much never safe anyway, so we should just delete operator= altogether. (I'd love to get rid of the copy-constructor too and just allow moves, but I think it still makes sense to copy-construct when combining a Twine argument with multiple different suffixes.)

dexonsmith requested changes to this revision.Oct 17 2020, 6:17 AM

Agree with the above.

This revision now requires changes to proceed.Oct 17 2020, 6:17 AM
vsk added a comment.Oct 19 2020, 1:16 PM

I won't be able to pick this back up anytime soon. If anyone would like to commandeer this patch, feel free to do so.