On Thu, 8 Feb 2024 17:20:23 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>> Jonathan Gibbons has updated the pull request with a new target base due to >> a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge remote-tracking branch 'upstream/master' into >> 8298405.doclet-markdown-v3 # Please enter a commit message to explain why >> this merge is necessary, # especially if it >> merges an updated upstream into a topic branch. # # Lines starting with >> '#' will be ignored, and an empty message aborts # the commit. >> - add test case contributed by @lahodaj >> - initial fix for source offset problem >> - remove unused imports >> - First pass at remove DocCommentTransformer from the public API. >> >> It is still declared internally, and installed by default, using the >> service-provider mechanism. >> If the standard impl is not available, an identity transformer is used. >> - updates for "first sentence" issues and tests >> - add info about provenance of `jdk.internal.md` module >> - MarkdownTransformer: tweak doc comments >> - MarkdownTransformer: change `Lower.replaceIter` to be `private final` >> - MarkdownTransformer: use suggested text for using streams >> - ... and 18 more: https://git.openjdk.org/jdk/compare/18e24d06...63dd8bf4 > > src/jdk.internal.md/share/classes/module-info.java line 41: > >> 39: // * package and import statements are updated >> 40: // * characters outside the ASCII range are converted to Unicode escapes >> 41: // * @SuppressWarnings("fallthrough") is added to getSetextHeadingLevel > > I wonder if it would be better to compile this module without (some) lint > checks. Is it possible? It's possible, but that would be a more global setting, whereas this is a very targeted modification. I guess it depends how much we want to import the code as-is, without knowing any lint-warts. FWIW, any module can be compiled with module-specific lint settings, if we choose to do so. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16388#discussion_r1486450189
