<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 6, 2014 at 6:43 PM, Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank" class="cremed">tobias@grosser.es</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br></div><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
In this context, I only want<br>
to enable all remarks.<br>
</blockquote>
<br></div>
I can see that. How to do this is really open for discussion. I could see us establishing two new flags '-Wall-remarks' for remarks and '-Wall-warnings' for warnings. Or, what I prefer, we could establish a new flag hierarchy e.g. with '-Reverything'.<br>

</blockquote><div><br></div><div>I quite like the notion of a new flag hierarchy.  Using -W seems like semantic overload.  -W already implies diagnostics about dubious constructs in the code. These notices are pure reporting on optimization activities.</div>

<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
5. Enable/Disable remarks with pragmas / per function<br>
<br>
Yes, there are a lot of things to do here. The diagnostic infrastructure<br>
already provides great features, e.g.:<br>
<br>
  - Enabling/Disabling diagnostics with pragmas and per function<br>
  - Nested diagnostic groups<br>
  - Enabling a diagnostic group, but disabling individual diagnostics<br>
    or this group.<br>
  - Good integration in tools through libclang<br>
  - ...<br>
<br>
However, the command line interface might need to be improved before we start adding a large number of remarks. Some goals I see:<br>
<br>
1) We want to reuse as much of the diagnostic infrastructure as possible<br>
2) We do not want to increase the complexity of the warning flags too much<br>
3) We still want to have a similar user interface as the warning flags provide<br>
4) People raised interest in upgrading remarks to warnings or errors<br>
   (I am personally not too sure about this one, but it already works<br>
    with -Werror=groupname)<br></blockquote><div><br></div><div>Yes to all.  Not so sure about #4.  Convert the reports into errors?  As in, fail the build if an inline didn't happen?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
Several people (including Chris) warned to build up an additional complex diagnostic system on the side, but as Chandler pointed out, we can most likely reuse most of the existing infrastructure but could still adjust the user interface if needed.<br>

</blockquote><div><br></div><div>Yes, the one additional ability we'll likely want is to direct these reports to files. Though that could be added later.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
I personally believe the best approach is to start small and let the design be driven by the intended use cases. If you are interested, I would propose to add a single diagnostic for the loop inliner using just the existing '-W' infrastructure e.g. with '-Winline-remarkers'.<br>

</blockquote><div><br></div><div>Agreed. I prefer an evolutionary approach.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

This both increases test coverage of the exiting features and also<br>
will help to get an idea of the needed features. At the same time, you could help reviewing my first patch on modularizing the clang diagnostic infrastructure. Again, something that may help to get an idea of where to head at this side.<br>

</blockquote><div><br></div><div>Sure. You mean r202475?</div><div><br></div><div><br></div><div>Diego.</div></div></div></div>