[cfe-dev] Fwd: warnings and error messages always go to standard error

[Geoff Levner via cfe-dev]

We have the same problem when using the C interface, however. When
clang_parseTranslationUnit() fails, there seems to be no way to recover the
diagnostics, which are printed to standard error. Apparently
clang_getDiagnosticSetFromTU() is there to give you access to diagnostics,
but it is only of use if you have a translation unit for it...

Geoff

On Tue, 28 Aug 2018 at 22:37, Geoff Levner <glevner at gmail.com> wrote:

> Aha! Thank you very much, Eli. That does the trick.
>
> [Actually, though, you have to pass createDiagnostics() a
> DiagnosticConsumer, which in my case is my TextDiagnosticPrinter.]
>
> Geoff
>
> On Tue, 28 Aug 2018 at 22:03, Friedman, Eli <efriedma at codeaurora.org>
> wrote:
>
>> On 8/28/2018 12:51 PM, Geoff Levner via cfe-dev wrote:
>>
>> Greetings, clangspeople,
>>
>> We are using Clang and LLVM in an application to compile and execute C++
>> code on the fly. If the code fails to compile, I would like to be able to
>> pop up a dialog box telling the user why. But warnings and error messages
>> go straight to standard error.
>>
>> I have tried passing a raw_string_ostream to TextDiagnosticPrinter
>> instead of errs(), but that seems to have no effect. What is that stream
>> actually used for? Am I doing something wrong? I have attached the code we
>> use to compile (simplified a bit).
>>
>>
>> The DiagnosticsEngine you pass to the Driver is only used for diagnostics
>> from the driver itself, not the resulting compilation.
>>
>> createDiagnostics() takes a DiagnosticsEngine as a parameter.  (If you
>> don't explicitly pass one, it will create one for you, which prints
>> diagnostics to stderr.)
>>
>> -Eli
>>
>> --
>> Employee of Qualcomm Innovation Center, Inc.
>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180829/48129bb8/attachment.html>