r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Chandler Carruth]

On Thu, Jan 9, 2014 at 4:07 AM, Alp Toker <alp at nuanti.com> wrote:

> I understand that, but the question is -- do you think that usage pattern
>> will be prevalent? Is it worth putting an external definition in the binary
>> *always* just to catch the case where we do a link-time-only flag?
>>
>> Put another way, is it really too burdensome to say that LSan does
>> require a compile time flag in order to support some usage patterns?
>>
>
> Who controls / defines the interface?
>

The sanitizers.


>
> This looks like a spectacular thinko rather than being something
> intentional -- is it possible to fix it to drop one or more underscores
> instead of devising workarounds?
>

I have no idea what you mean. This was a well considered change, and part
of a design that has been developed over quite some time on the lists. None
of these are workarounds?


>
> There's never a valid reason to require user code to define reserved names
> (although it's sometimes OK for user code to _use_ reserved names).
>

You keep making this assertion, but I still don't find any backing for it
in the standard. I'm happy to check with some of my fellow members of the
committee, but I would be surprised if they drew the distinction you are
drawing here.


>
> I'm heading out for a couple of hours, please gate this behind a macro or
> revert until a resolution is found.


Alp, I really don't think this is reasonable. This change, and the lead up
to the change, were discussed on the list with code review. I understand
you have some high level design concerns, but there doesn't appear to be
broad agreement with them and I don't think it is reasonable to block
progress here while we sort them out.

I'm happy to continue this discussion, but I do not think that this needs
to be reverted, and I do not think we need to block progress on actually
getting leak checking into the sanitizers and the LLVM and Clang bootstrap
during that discussion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/793c29e3/attachment.html>