<!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>