r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Alp Toker]

On 14/01/2014 07:23, Kostya Serebryany wrote:
>
>
>
> On Tue, Jan 14, 2014 at 1:47 AM, Richard Smith 
> <richardsmith at google.com <mailto:richardsmith at google.com>> wrote:
>
>     On Mon, Jan 13, 2014 at 8:03 AM, Alp Toker <alp at nuanti.com
>     <mailto:alp at nuanti.com>> wrote:
>
>
>         On 13/01/2014 15:02, Kostya Serebryany wrote:
>
>             Alp, others,
>
>             Now that there is no urgent issue I'd like to return to
>             the discussion about names with "__" prefix in sanitizer
>             run-times.
>
>
>         If you're OK to conditionalize the code so it's only defined
>         in sanitizer builds, that's fine and as Sean pointed out
>         there's already plenty of precedent -- it's what every
>         software project does to define "__" prefixed weak link
>         functions like libc malloc hooks.
>
>     This discussion is so vastly far from the best use of any of our
>     time. Let's just restore the name we had before and wrap the
>     definition in __has_feature(leak_sanitizer). I think that will
>     make everyone happy. OK?
>
>
> There is no __has_feature(leak_sanitizer) and it can't be implemented 
> with reasonable semantics (discussed here before).
> Unless someone objects, I'll change the code back to use 
> __lsan_is_turned_off and hide it under __has_feature(address_sanitizer),
> then I will revert my change that added an alternative to 
> __lsan_is_turned_off (LeakSanitizerIsTurnedOffForTheCurrentProcess)
>
> This means that  -Wreserved, -Wreserved-macros, -Wreserved-identifiers 
> (once implemented)
> will not work on clang bootstrap in AddressSanitizer mode,
> but let Alp handle this if it ever becomes a problem.

Yes, as long as the first declaration is in your system header we can 
work with that.

Thanks Kostya.

Alp.


> --kcc

-- 
http://www.nuanti.com
the browser experts