non-exiting diagnostic handler for LTO code generator

[Hans Wennborg via llvm-commits]

+Tom for 3.7.1.

On Fri, Sep 11, 2015 at 11:54 AM, Rafael Espíndola
<rafael.espindola at gmail.com> wrote:
> LGTM. Thanks!
>
> Hans, this is probably a good candidate for 3.7.1.
>
>
> On 11 September 2015 at 11:48, Gao, Yunzhong
> <yunzhong_gao at playstation.sony.com> wrote:
>> Fixed. Thanks.
>>
>> ________________________________________
>> From: Rafael Espíndola [rafael.espindola at gmail.com]
>> Sent: Friday, September 11, 2015 5:56 AM
>> To: Gao, Yunzhong
>> Cc: Duncan P. N. Exon Smith (dexonsmith at apple.com); Peter Collingbourne (peter at pcc.me.uk); llvm-commits at lists.llvm.org
>> Subject: Re: non-exiting diagnostic handler for LTO code generator
>>
>> As you point out llvm-lto is just a testing tool, so this is fine.
>>
>> Can you avoid the code duplication between the two constructors? The
>> lambda uses no local state, so it can be converted to a static global
>> function, no?
>>
>>
>>
>> On 10 September 2015 at 22:02, Gao, Yunzhong
>> <yunzhong_gao at playstation.sony.com> wrote:
>>> Hi Rafael,
>>>
>>> Writing a test with llvm-lto turns out to be slightly more tricky than I thought it would be. llvm-lto does something like:
>>>   if (!CodeGen.addModule(Module.get()))
>>>     return 1;
>>> So with my patch, addModule() will no longer call exit(1) on errors in modules, but when it returns to the main()
>>> function of llvm-lto, it silently returns 1, and I cannot distinguish between exit(1) and "return 1" within lit. My
>>> current attempt (attached) is to make llvm-lto print an extra message before returning 1, so that lit can FileCheck
>>> that. Is this acceptable? I think it does make llvm-lto print excessive diagnostics, but hopefully llvm-lto is used only
>>> for testing and therefore it does not matter,
>>>
>>> - Gao
>>>
>>>
>>> ________________________________________
>>> From: Rafael Espíndola [rafael.espindola at gmail.com]
>>> Sent: Wednesday, September 09, 2015 5:33 AM
>>> To: Gao, Yunzhong
>>> Cc: Duncan P. N. Exon Smith (dexonsmith at apple.com); Peter Collingbourne (peter at pcc.me.uk); llvm-commits at lists.llvm.org
>>> Subject: Re: non-exiting diagnostic handler for LTO code generator
>>>
>>> I think the included patch is correct. You should be able to write a
>>> test for it with llvm-lto, no?
>>>
>>