================
@@ -15460,6 +15461,108 @@ void Sema::CheckThreadLocalForLargeAlignment(VarDecl 
*VD) {
   }
 }
 
+/// Process a variable definition whose mangled name may be listed in
+/// '-mloadtime-comment-vars=': attach an implicit attribute to supported
+/// string variables so CodeGen preserves them as loadtime identifying
+/// strings, and warn when a named variable cannot be preserved.
+static void processForLoadTimeCommentVar(Sema &S, VarDecl *VD) {
+  // Declarations that cannot be name-matched are silently skipped: an
+  // automatic variable has no symbol of its own, and neither does a template
+  // pattern (only its specializations do, and those are processed
+  // separately). Only definitions are considered.
+  if (VD->hasLocalStorage())
+    return;
+  if (VD->isTemplated())
+    return;
+  if (VD->isThisDeclarationADefinition(S.Context) != VarDecl::Definition)
+    return;
+
+  // Only plain `char` pointers/arrays with an initializer are supported; a
+  // matched variable of any other form (int, struct, wide or explicitly
+  // signed/unsigned character types, no initializer, ...) is silently
+  // ignored.
----------------
AaronBallman wrote:

I'm wondering why silently ignored? If a user went to the trouble of coming up 
with a valid mangled name, it seems like they would expect that to do something 
and so silently ignoring what they specified will be hard for them to debug. Is 
my intuition wrong?

(Additionally, I wonder about why we would silently ignore an invalid mangled 
name too; mangling is not easy to do by hand and so there's a reasonable chance 
for the user to have typos, so I would have imagined they'd want to know about 
this scenario too. But it does seem somewhat more defensible if the variable is 
conditionally defined (e.g., wrapped in `#ifndef NDEBUG` or something) so I'm 
not strongly opposed, just raising the debuggability question.)

https://github.com/llvm/llvm-project/pull/187986
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to