[cfe-dev] Notes in Clang diagnostics and LLVM DiagnosticInfo
Richard Smith
richard at metafoo.co.uk
Mon Feb 24 15:07:04 PST 2014
On Sun, Feb 23, 2014 at 1:21 AM, Tobias Grosser <tobias at grosser.es> wrote:
> On 02/23/2014 10:08 AM, tsett wrote:
>
>> Hi Tobias,
>> I got the problem.
>> I use the DiagnostigBuilder::setForceEmit() for this.
>> An instance of DiagnostigBuilder will be returned if you use the
>> report-function.
>>
>
> Good point. The following patch makes my messages appear again:
>
> --- a/lib/CodeGen/CodeGenAction.cpp
> +++ b/lib/CodeGen/CodeGenAction.cpp
> @@ -384,7 +384,9 @@ void BackendConsumer::DiagnosticHandlerImpl(const
> DiagnosticInfo &DI) {
>
> // Report the backend message using the usual diagnostic mechanism.
> FullSourceLoc Loc;
> - Diags.Report(Loc, DiagID).AddString(MsgStorage);
> + DiagnosticBuilder DB = Diags.Report(Loc, DiagID);
> + DB.setForceEmit();
> + DB.AddString(MsgStorage);
>
> We could use this to either force printing of all backend diagnostics or
> only the notes. However, I am afraid that would break existing flags to
> suppress diagnostics.
>
Please don't do this. Notes are designed to attach additional information
to the prior non-note diagnostic, and this assumption is pervasive within
the diagnostics mechanism inside clang, as well as in the model we present
to our users and in our API.
Adding an 'info' or 'remark' level for diagnostics seems much more in line
with our existing design. It may be of somewhat limited utility, but the
cost of having this support seems rather low. (In the long term, I assume
that end users of polly will not care about these diagnostics, and that
they're primarily to aid people developing or testing polly -- and
certainly this does not match how other optimization passes in LLVM report
debug or progress information to their users.) FWIW, some other compilers
have a 'remark' diagnostic level, for messages that don't rise to the level
of 'warning'.
Another option is to only set this for plugin diagnostics. However, this
> would not solve the problem for the vectorizers which may need similar
> reporting capabilities.
>
>
> Tobias
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140224/5188bed8/attachment.html>
More information about the cfe-dev
mailing list