[jdk19] RFR: 8287379: Using @inheritDoc in an inapplicable context shouldn't crash javadoc [v2]

[Pavel Rappo]

> This rights the wrongs of JDK-8008768. For more information, see the respective CSR.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Merge remote-tracking branch 'jdk19/master' into 8287379
 - Update DocTest
   
   1. Removes @inheritDoc from these type of declarations:
        * class and interface
        * constructor
   2. Removes empty declarations.
   3. Updates @apiNote, @implSpec and @implNote definitions to match those
      of JDK API.
   4. Fixes a few typos.
 - Add tests
 - Disallow @inheritDoc in type declarations
   
   This undoes undocumented changes introduced by 8008768.
 - Do not warn on inline misuse
   
   The type of a declaration (module, class or interface, constructor,
   method, etc.) for which a tag is applicable, is orthogonal to the type
   of the tag (inline, block, bimodal).
   
   The code up the stack knows which type of tags it has collected. If
   those tags are of type other than expected, it's a programming error.
 - Doclint shouldn't warn on inapplicable conditions
   
   overview.html and doc-files/**/*.html files cannot have
   a main description or be an empty comment. At the very least,
   the check for being "an empty comment" for such files cannot be
   performed by checking if the files contain any block tags. Block tags
   are applicable to a program element, which those files are not.
 - Expand checkTags to include non-inline tag
   
   Aside from @inheritDoc, which is context-dependent, we now have
   a bimodal tag such as {@return}/@return.
 - Remove another null-check
   
   The `element` cannot be null for various reasons:
   
   1. If `element` were null, `getCommentHelper` would NPE (because it
      calls `Utils.getDocCommentInfo` which NPEs on a null element).
   2. The Overview and Html files correspond to the OverviewElement
      and DocFileElement pseudo-elements, which are passed to checkTags
      when respective files are processed.
   
   Existing tests and ad-hoc experiments support that.
 - Remove null-check
   
   We can do this safely because the `trees` parameter is never null in
   any of the 3 call sites of the checkTags method.

-------------

Changes:
  - all: https://git.openjdk.org/jdk19/pull/54/files
  - new: https://git.openjdk.org/jdk19/pull/54/files/2a81009a..e3308c10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk19&pr=54&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk19&pr=54&range=00-01

  Stats: 1623 lines in 78 files changed: 1221 ins; 233 del; 169 mod
  Patch: https://git.openjdk.org/jdk19/pull/54.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/54/head:pull/54

PR: https://git.openjdk.org/jdk19/pull/54