Add openArray[char] overloads to std/parseutils

[beef331]

Summary

Makes all the std/parseutils operations use openArray[char].
Keeps string overloads in std/parseutils as they are still useful.

---

Notes for Reviewers

• leave additional context for reviewers
• maybe specific requests or areas of focus

[zerbina]

Thank you for the pull request.

As mentioned on Matrix, the CI failure is due to the csources compiler not supporting toOpenArray at compile time. The csources compiler was updated fairly recently, and I personally think another update is not yet warranted.

I know that the start parameter is largely redundant when the input is a slice, but please only use openArray instead of string for now. The start parameter already has a default value, so at least the callsites aren't forced to use it.

Once s[x..y] returns an openArray (I personally think it should), the start parameter can be removed, as the overhead of writing, e.g., parseHex(s[start..^1]) compared to parseHex(s, start) is negligible, in my opinion.

[zerbina]

This won't work. The procedure is a .compilerproc, meaning that the compiler (usually the code generators) looks it up and emits a call to it internally, relying on the exact signature of the procedure.

Even if you update the places in the compile relying on the signature, the csources compiler won't know about this.

If you're interested, you could (in a separate PR) turn the procedure into a normal one, also removing the mParseBiggestFloat magic in the process, which would allow for using openArray as the parameter afterwards. Maybe there once was a good reason for the procedure to be magic, but I don't see why this is the case now.

[beef331]

Does this not result with the same sort of issue, the bootstrapped compiler expects nimParseBiggestFloat to be inside system and marked with {.compilerproc.} as such it will complain that it's missing nimParseBiggestFloat if one removes the annotation?

I suppose to bootstrap the procedure could still be labelled a compiler proc until the csources are updated.

[zerbina]

I suppose to bootstrap the procedure could still be labelled a compiler proc until the csources are updated.

Yep, that's roughly what you'd do.

It's not exactly obvious, but this is how it'd work:

1. keep the nimParseBiggestFloat procedures in .compilerproc in strmantle and jssys
2. only enable the parseBiggestFloat magic implementation when booting (i.e., when defined(nimKochBootstrap))
3. move the nimParseBiggestFloat implementation from strmantle and jssys into parseutils.parseBiggestFloat (only used when not in bootstrap mode)
4. add a VM hook for parseBiggestFloat and remove all remnants of the magic