[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
@@ -57,7 +57,7 @@ class DeclarationFragments {
Keyword,
Attribute,
NumberLiteral,
-StringLiteral,
+StringRef,
bjacob wrote:
good catch! i'll pore over the actual diff line by line to catch more things
like this, but I wanted to first see if this PR would be shot down at a higher
level :-)
https://github.com/llvm/llvm-project/pull/122366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
@@ -57,7 +57,7 @@ class DeclarationFragments {
Keyword,
Attribute,
NumberLiteral,
-StringLiteral,
+StringRef,
bjacob wrote:
Thanks for the heads up -- will fix one by one.
Also, note to self: let's leep `StringLiteral` around as deprecated to give
downstreams a smoother transition.
https://github.com/llvm/llvm-project/pull/122366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
bjacob wrote: > I didn't really understand the last paragraph of the PR description. How does > using StringRef instead of StringLiteral reduce relocations? It does not - sorry if that was confusingly worded. What I was trying to say is that using a plain `const char[]` instead of a StringLiteral avoids one relocation. The problem then with StringLiteral is that its existence and name naturally lead people to use it for things that could have been a `const char[]` , resulting in more relocations. Maybe not having a class named `StringLiteral` will result in more string literals remaining `const char[]`. https://github.com/llvm/llvm-project/pull/122366 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
bjacob wrote:
@s-barannikov
> > * the `strlen` is NOT constant-evaluated on MSVC, even the latest version.
>
> The godbolt link shows otherwise?
This is what I see in godbolt - to me this loop looks like strlen:
https://github.com/llvm/llvm-project/pull/122366
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
bjacob wrote: @jrtc27 > const char[] allocates storage for the string contents though, so takes up > space in memory if the string can be merged with others at compile or link > time. There are multiple things being traded off here, and PDE vs PIC/PIE > complicates the story further. So it's not just as simple as "use const > char[] whenever you can". Ah, thanks for the explanation... I really hadn't thought of that, but IIUC you're saying that the indirection (referring to a string via a pointer to it) allows merging storage when a string literal is a substring of another, while using raw `const char[]` doesn't allow any reuse unless the string literal exactly match. Really interesting, but I still wonder -- this sounds like a fancier kind of optimization that probably won't be able to apply in a majority of cases (it needs literals to be substrings of each other?) while the relocations are every single time. https://github.com/llvm/llvm-project/pull/122366 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] [clang-tools-extra] Remove `StringLiteral` in favor of `StringRef` (PR #122366)
https://github.com/bjacob edited https://github.com/llvm/llvm-project/pull/122366 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
