<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<br>
<blockquote type="cite" cite="mid:CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>OTOH a deeper refactoring would replace the <span style="font-family:monospace">LintCategory</span> enum
with something more complicated in a tree-like hierarchy.</div>
<div><br>
</div>
<div>Are there any concrete design thoughts on this yet?<br>
</div>
</div>
</div>
</div>
</blockquote>
We have no concrete design on this yet. But this is influenced by
making Lint more pluggable. E.g. perhaps the families will be
reflected in some sealed hierarchy that will be part of the JDK,
something that programs can reason about.
<blockquote type="cite" cite="mid:CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><span style="font-family:arial,sans-serif">Dumb
question: would adding a new compiler "step" be (roughly
speaking) as straightforward as adding </span><span style="font-family:monospace">CompileState.WARN</span>
and doing<span style="font-family:arial,sans-serif">
something like this?</span></div>
<div><span style="font-family:arial,sans-serif"><br>
</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">-
generate(desugar(flow(attribute(x))));</span></div>
<div style="margin-left:40px"><span style="font-family:monospace">+
generate(desugar(warn(flow(attribute(x)))));</span></div>
<div style="margin-left:40px"><span style="font-family:monospace"><br>
</span></div>
<div><span style="font-family:arial,sans-serif">As for
consolidating all of the warning logic, I like that idea
and the potential ability to make warnings more
pluggable. The refactoring would be tedious but
straightforward, at least for those warnings that simply
inspect the information already being </span><span style="font-family:arial,sans-serif">gathered</span><span style="font-family:arial,sans-serif"> by the compiler.</span></div>
</div>
</div>
</div>
</blockquote>
<p>I believe having a new step consolidating the various logic is a
good way to approach this. I suspect that, when doing this
exercise, we will find commonalities between the various Linters,
and maybe some abstract class, with some entry point will be the
start of a more pluggable way to think about these problems (maybe
this API will initially be javac-only, but when mature enough we
can re-consider).</p>
<p>We should also look at what others have done in this space - most
notably ErrorProne.<br>
</p>
<blockquote type="cite" cite="mid:CANSoFxsEJBO=UwZtV=6MhToH5-HOOYnAAJhzkx_Vm8n+fosiMg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_quote">
<div><span style="font-family:arial,sans-serif"><br>
</span></div>
<br>
<div>Should I create issues for the following? <span style="font-family:arial,sans-serif">Let me know your
thoughts:</span><br>
</div>
<div>
<ul>
<li>Minor lint refactoring cleanups<br>
</li>
<li>Add a new <span style="font-family:monospace">warn()</span>
compiler step after flow analysis</li>
<ul>
<li>ThisEscapeAnalyzer is a charter member<br>
</li>
</ul>
<li>Refactor to move lint warnings into the warn() step
(umbrella)</li>
<ul>
<li>Add issues over time under this umbrella for
migrating existing warnings<br>
</li>
<li>Depends on: Add new warn() step</li>
</ul>
<li>Umbrella issue for the <span style="font-family:monospace">@SuppressWarnings </span>cleanup</li>
<ul>
<li>Existing cleanup issues go under here<br>
</li>
</ul>
<li>Suppression warnings (this proposal)</li>
<ul>
<li>Depends on: Add new warn() step</li>
<li>Depends on: Umbrella issue for the <span style="font-family:monospace">@SuppressWarnings </span>cleanup</li>
<li>Depends on: Minor lint refactoring cleanups</li>
</ul>
</ul>
</div>
</div>
</div>
</div>
</blockquote>
<p>Yep. Not sure whether this proposal depends on the
@SuppressWarnings cleanup: in principle you could also add the
analysis and disable it when building the JDK, and let the various
components to be updated at their pace.</p>
<p>Maurizio</p>
<br>
</body>
</html>