Stand-alone leak sanitizer builds are supported with -fsanitize=leak,
adds an attribute for consistency with the rest of the sanitizer attributes.
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.
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.
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.