Add __has_feature(leak_sanitizer)

[fjricci]

Summary

Stand-alone leak sanitizer builds are supported with -fsanitize=leak,
adds an attribute for consistency with the rest of the sanitizer attributes.

[kcc]

I'm not sure about this one.
standalone lsan is a link-time feature only, it doesn't change the compilation, so the argument of consistency doesn't apply.

[fjricci]

Currently, the way that we tell users to gate on sanitizer-specific behavior is with __has_feature(foo_sanitizer), as far as I know, it's the only way to do so. LSan provides several API functions for users, ie __lsan_ignore_object. If a user program wants to use these API functions in their program, they need a way to check that LSan is enabled at compilation time (even if LSan doesn't actually modify the compile step). I'm not sure of a better or more consistent way to allow that to happen.

[m.ostapenko]

In D34210#780520, @fjricci wrote:

Currently, the way that we tell users to gate on sanitizer-specific behavior is with __has_feature(foo_sanitizer), as far as I know, it's the only way to do so. LSan provides several API functions for users, ie __lsan_ignore_object. If a user program wants to use these API functions in their program, they need a way to check that LSan is enabled at compilation time (even if LSan doesn't actually modify the compile step). I'm not sure of a better or more consistent way to allow that to happen.

Can't you use weak hooks in your code for this purpose?

[fjricci]

Weak hooks do provide a good solution, abandoning for now (although it may need to be reconsidered if we get a windows LSan port up and running).

[fjricci]

As I've looked into this further, I do think we need has_feature(leak_sanitizer) after all. For example, if a user program calls pthread_create() with a custom stack size, leak sanitizer will intercept the call to pthread_create(), and may modify the stack size set by the user (lsan's interceptor for pthread_create calls AdjustStackSize in sanitizer_common). Without has_feature(leak_sanitizer), there's no good way for the user program to account for these sorts of modifications. There are most likely other interceptors which will cause similar issues, this is just the first example I ran into.

[rnk]

If LSan is a runtime thing, why not use weak hooks or something to detect LSan at runtime instead of using a macro?

[kcc]

In D34210#785828, @rnk wrote:

If LSan is a runtime thing, why not use weak hooks or something to detect LSan at runtime instead of using a macro?

+1

For a run-time-only feature the checking should also be run-time-only (not compile-time)

[fjricci]

Yeah, I think that makes sense. Life will get a bit tricky when Windows support gets added and we can't use weak hooks to determine whether LSan is running, but I'm sure there's a way to handle that.

[smeenai]

COFF supports weak externals: https://stackoverflow.com/a/11529277/382079. Would it suffice here?

[fjricci]

In D34210#804084, @smeenai wrote:

COFF supports weak externals: https://stackoverflow.com/a/11529277/382079. Would it suffice here?

Looks like it could work, thanks.

lib/Lex/PPMacroExpansion.cpp

return llvm::StringSwitch<bool>(Feature)
       .Case("attribute_diagnose_if_objc", true)
       .Case("blocks", LangOpts.Blocks)
       .Case("c_thread_safety_attributes", true)
       .Case("cxx_exceptions", LangOpts.CXXExceptions)
       .Case("cxx_rtti", LangOpts.RTTI && LangOpts.RTTIData)
       .Case("enumerator_attributes", true)
       .Case("nullability", true)
       .Case("nullability_on_arrays", true)
+      .Case("leak_sanitizer", LangOpts.Sanitize.has(SanitizerKind::Leak))
       .Case("memory_sanitizer", LangOpts.Sanitize.has(SanitizerKind::Memory))
       .Case("thread_sanitizer", LangOpts.Sanitize.has(SanitizerKind::Thread))
       .Case("dataflow_sanitizer", LangOpts.Sanitize.has(SanitizerKind::DataFlow))
       .Case("efficiency_sanitizer",
             LangOpts.Sanitize.hasOneOf(SanitizerKind::Efficiency))
       // Objective-C features
       .Case("objc_arr", LangOpts.ObjCAutoRefCount) // FIXME: REMOVE?
       .Case("objc_arc", LangOpts.ObjCAutoRefCount)

test/Lexer/has_feature_leak_sanitizer.cpp

+// RUN: %clang_cc1 -E -fsanitize=leak %s -o - | FileCheck --check-prefix=CHECK-LSAN %s
+// RUN: %clang_cc1 -E  %s -o - | FileCheck --check-prefix=CHECK-NO-LSAN %s
+
+#if __has_feature(leak_sanitizer)
+int LeakSanitizerEnabled();
+#else
+int LeakSanitizerDisabled();
+#endif
+
+// CHECK-LSAN: LeakSanitizerEnabled
+// CHECK-NO-LSAN: LeakSanitizerDisabled