File "ql/java/ql/src/semmle/code/java/Type.qll" contains a non-ASCII character at the location marked with | in:

 extends Class {
  Record() { isRecord(this) }

  // JLS 16 |

ASCII check failed!

Yeah, I know, I added the the section sign § on purpose...
I wondered why the other QLDoc comment wrote out "section" in full. Sorry for this trouble, but I really could not have known that there is an ASCII-only restriction.
I don't think there is any document here mentioning it (or I missed it), the QL spec apparently has no such restrictions and locally for me the query library is compiled just fine. (another reason for #5480)

If you want I can replace / remove those §, though would it make sense to relax this restriction to allow ISO-8859-1 / Latin 1 (which § is part of), maybe excluding undefined chars and the NBSP?

Note however, that as mentioned in the description there is currently little value in merging this pull request.

Sorry that this comment is somewhat reproachful, it just feels so uncomfortable to create pull requests which fail, wasting your and my time. If I would at least see the CI failure I could (hopefully) fix problems because you even have a first look on it.
(Though some of my previous pull requests were really in a bad state which I could have detected myself locally.)

Tested this against the latest extractor: can confirm the tests pass without the QL changes (i.e., the extractor is populating the implicit modifiers for us)

Just the test merged as #6604, as the extractor is already flagging these classes as static and/or final for us.

@smowton, thanks for merging the tests. Ideally the NestedType.isStatic() documentation would be updated like it was proposed by this pull request. However, the question is if there is any point in overriding the predicate in the first place when implicit modifiers are reported anyways. As mentioned in #5682 (comment) there is probably some cleanup need to remove this special casing. Do you want me to create a new issue for that?

Happy to merge a docs change (don't use the section character §, since the codeql source code is intentionally entirely ASCII). Probably worth noting that the extractor provides some of the advertised functionality.

On cleaning up any duplication between the extractor and the QL library, I'm disinclined to spend time on it: we can only possibly make the situation worse for users, and I'll need to check I've written an exhaustive suite of tests to be sure I haven't introduced a regression.

@smowton, I have instead created #6797 now to remove the overwritten QLDoc because it adds in my opinion not much value (and in other cases it is not listed either which implicit modifiers are detected).