[LLVMdev] Out-of-source subclassses vs. LLVM's RTTI system

[Christian Convey]

Actually, I see an additional problem as well.  Even if I did manage to
create my own out-of-source subclass of DiagnosticInfoOptimizationBase,
there's still the question of how it would handle "Remark" severity.

To be consistent with the rest of the diagnostic classes, my
subclass's *isEnabled
*method should probably consult the *PassRemarksAnalysisOptLoc* object when
handling a message with severity = "remark".  Unfortunately the
*PassRemarksAnalysisOptLoc* object has static linkage, so my code can't
easily access it.

The only way I can think to query it is to creaet a throw-away instance of
some subclass of *DiagnosticInfoOptimizationBase*, and to provide that
dummy's constructor with the same pass name that was provided to my class's
constructor.  Then I could call that dummy instance's "isEnabled" method to
find out whether or not my own code should emit the message.

Unless someone has a cleaner way to do this, I think I'll just accept that
the DiagnosticInfo stuff isn't designed for my use case, and move on.

On Wed, Jun 24, 2015 at 1:00 PM, Christian Convey <
christian.convey at gmail.com> wrote:

> Hi Tobias
>
> On Wed, Jun 24, 2015 at 12:43 PM, Tobias Grosser <tobias at grosser.es>
> wrote:
>
>> Maybe have a look at Polly's lib/Analysis/ScopDetectionDiagnostic.cpp and
>> lib/Analysis/ScopDetection.cpp. We use LLVM's diagnostics in a loadable
>> module without modifying LLVM's DiagnosticKind enum.
>>
>
> Thanks very much for the suggestion.  It looks like Polly's approach is
> the same as my initial approach: just call the most-appropriate-seeming
> llvm::emit...Remark...(...) method.
>
> I can use that as a fallback approach, if needed.  But I was hoping
> implement a function for emitting diagnostic info, where one of the
> parameters was the severity level (llvm::DiagnosticSeverity).  I'm
> particularly interested in drawing a distinction between "remarks" (which
> should be optionally filtered) and "warnings" (which should always be sent
> to errs())
>
> The DiagnosticInfoOptimizationBase supports the exact set of details I
> care about.  Unfortunately it's an abstract class, which is why I'm in my
> current situation.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/f65e4fa2/attachment.html>