llvm dev - Jun 2015 - [LLVMdev] Out-of-source subclassses vs. LLVM's RTTI system

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/b5795748/attachment.html>

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>

On 06/24/2015 07:17 PM, Christian Convey wrote:
> 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.
Sorry, I am a little in a rush, but did you see the 
getNextAvailablePluginDiagnosticKind() method. This should allow you to 
define your own DiagnosticKinds. I am not sure if this is sufficient for 
you, but in general the diagnostic infrastructure is supposed to be 
useable from plugins. It may happen that some features don't work 
currently, but I don't see a reason why we would not want to add/expose 
missing functionality in case the need arises.

Best,
Tobias