styleCheck: Fix some inconsistent identifiers

[ee7]

This PR fixes some problems that are reported when compiling with --styleCheck:error.

The commits are atomic: the first commit acts on mismatched identifiers; the second deals with snake_case -> camelCase.

[timotheecour]

@ee7 thanks, merged it (not controversial, just style fixes). Was this everything for stdlib?

[ee7]

Was this everything for stdlib?

@timotheecour This PR covered all of the least controversial ones - the ones that are simple mismatches and unexported snake_case identifiers in modules that have no other styleCheck problems.

I'll make another PR that fixes styleCheck complaints about the capitalization of the first character of an unexported identifier, like:

Nim/lib/pure/ropes.nim

Line 59 in 297c8e4

N {.threadvar.}: Rope # dummy rope needed for splay algorithm

After that, the remaining ones in the stdlib are less straightforward. Compile the below with --styleCheck:error to see most of them:

import
  db_mysql,
  db_odbc,
  db_postgres,
  inotify,
  nre

Here, styleCheck complains about the style of exported symbols like:

Nim/lib/posix/inotify.nim

Line 76 in 297c8e4

iterator inotify_events*(evs: pointer, n: int): ptr InotifyEvent =

To my understanding, changing these in a backwards-compatible way requires either:

• Adding some -d:styleCheckFoo (causing --styleCheck:error to ignore or produce deprecation warnings for symbols that we change) or
• Adding special cases to the implementation of --styleCheck:error that produce deprecation warnings rather than outright errors.

Are there any other options?

I'll leave it to others to decide whether we want to change the style of such exported symbols, and if so, to decide the best approach.

One half-measure is to develop a new version of styleCheck that only checks that the style of an identifier matches that in its declaration (without checking the style of the declaration itself). This was proposed in #15848.

[ee7]

I have a WIP branch (unpushed) that attempts to add --styleCheck:error to CI. That would make fixing styleCheck problems less of a moving target - we'd always know exactly which modules currently compile with --styleCheck:error.

However, would that be something we'd actually want to merge? It might add too much friction to PRs if styleCheck problems cause CI to indicate failure.

To reduce the friction, it would be possible to add it as a standalone CI check (say, as a dedicated GitHub Actions workflow), so that a styleCheck error only causes one CI check to indicate failure. But that adds clutter and complexity, and maybe gives styleCheck more importance than it deserves.

[timotheecour]

how about this:
add support for: --styleCheck:fullyqualifiedname:hint|error|off, for eg:
--styleCheck:stdlib.inotify.inotify_events:hint
where fullyqualifiedname is pkg.module.symbol (reusing same algo as used in vmops, which also supports *, eg --styleCheck:stdlib.inotify.*:hint)

that way we can:

• more freely fix stdlib without breaking user code
• allow fixing code in a more granular way

this feature can be backported all the way to 1.0.x to make life easier

--styleCheck:fqname:hint would work the way you'd expect:

# this errors except for foo1, foo2
--styleCheck:error --styleCheck:foo1:off --styleCheck:foo2:off

this would also fix your 2nd point, since we'd be able to whitelist modules where stylecheck is currently problematic.

And yes, we should add styleCheck to CI

note: caution with #10201