fix: spec compliant parseInt

[MaxGraey]

• more rejection tests

• more tests which mixed different prefixes and radices

• fixes edge cases for parseInt

• proper generic variants of strtol for F64.parseInt and F32.parseInt

• I've read the contributing guidelines

[dcodeIO]

Iiuc, on Discord it was also reported that global parseInt returns 0 instead of NaN for inputs like "this is not semantically equal to 0". Does this PR fix this as well, does not attempt to fix it, or was this a false alarm?

Example given was

assert(parseInt("this is not semantically equal to 0") == 0)
assert(parseInt("this is not semantically equal to 0") == parseInt("0"))

mentioning that these asserts pass, which seems weird given that global parseInt is

export function parseInt(str: string, radix: i32 = 0): f64 {
  return strtol<f64>(str, radix);
}

[dcodeIO]

From a quick test it seems that

parseInt("") // returns NaN as expected but
parseInt("abc") // returns 0, which is strange

[MaxGraey]

In my tests parseInt("abc") equal to NaN but not a zero.

See test case below

[MaxGraey]

Iiuc, on Discord it was also reported that global parseInt returns 0 instead of NaN for inputs like "this is not semantically equal to 0". Does this PR fix this as well, does not attempt to fix it, or was this a false alarm?

It fix already halfbacked solution which just not properly tests. So as you suggested in discord solution:

let parsedFloat = parseInt('bad input');
if(isNaN(parsedFloat)) {
   // fail
} else {
  // success
}

Just not worked. Current PR fix this.

[dcodeIO]

Great, thanks, looks good then with the other comment above addressed :)

[MaxGraey]

Alright. It seems all cases handled properly

[github-actions]

🎉 This PR is included in version 0.13.5 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀