<div dir="ltr"><div dir="ltr">On Thu, Mar 6, 2025 at 9:45 AM Magnus Ihse Bursie <<a href="mailto:magnus.ihse.bursie@oracle.com">magnus.ihse.bursie@oracle.com</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But having warning suppression that does not make sense for a given <br>
compiler is not necessary a problem, and if it should be flagged, it <br>
should be something you opt into, and possibly, as Joe suggests, somehow <br>
lie outside normal warnings.</blockquote><div><br></div><div>I did think about this question of interactions between <span style="font-family:monospace">-Werror</span>, <span style="font-family:monospace">-Xlint:all</span>, and different compiler versions with respect to these new warning categories. In particular, thinking through the scenarios is why the <span style="font-family:monospace">-Xlint:suppression</span> flag is ignored unless the <span style="font-family:monospace">-Xlint:options</span> flag is also enabled (see below).</div><div><br></div><div>Here are my thoughts... please check my logic:</div><div><ul><li>In the case of <span style="font-family:monospace">@SuppressWarnings</span> annotations:</li><ul><li>What if a compiler doesn't recognize <span style="font-family:monospace">@SuppressWarnings("suppression")</span>?</li><ul><li>No problem - it's already the case that unrecognized keys are ignored</li></ul><li>What if two compiler versions handle some warning <span style="font-family:monospace">"foo"</span> differently, so that one warns where one doesn't?</li><ul><li>In this case <span style="font-family:monospace">@SuppressWarnings("foo")</span> will be unnecessary in one case but not the other</li><ul><li>In the latter you'd then get a <span style="font-family:monospace">"suppression"</span> warning if enabled and the compiler supports it</li></ul><li>But this happens all the time - i.e., a new warning is introduced or an existing warning's behavior changes</li><li>The usual answer is to add <span style="font-family:monospace">@SuppressWarnings("foo")</span> to suppress the warning in the compiler version where it occurs</li><li>Similarly, the answer here is to add <span style="font-family:monospace">@SuppressWarnings("suppression")</span> to suppress the warning in the compiler version where it occurs</li></ul></ul><li>In the case of <span style="font-family:monospace">-Xlint:suppression</span><span style="font-family:monospace">-option</span> flags:</li><ul><li>It's always safe to add <span style="font-family:monospace">-Xlint:-suppression-option</span> to a build to restore the current behavior IF every compiler version knows that flag</li><li>If some compiler version doesn't know <span style="font-family:monospace">-Xlint:-suppression</span><span style="font-family:monospace">-option</span> then <span style="font-family:monospace">-Xlint:-options</span> also works</li><li>So there's always a way to disable suppression warnings, regardless of whether the compiler knows about <span style="font-family:monospace">"suppression</span><span style="font-family:monospace">-option</span><span style="font-family:monospace">"</span></li><li>Using<span style="font-family:monospace"> -Xlint:-options</span>  is only a temporary measure until all compiler versions support "<span style="font-family:monospace">suppression</span><span style="font-family:monospace">-option</span></li></ul></ul><div>-Archie</div><div><br></div></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">Archie L. Cobbs<br></div></div>