mirror of
https://github.com/nim-lang/Nim.git
synced 2026-02-12 22:33:49 +00:00
13110fc5d3
fixes #24233 Integer literals with type `int` can match `int64` with a generic match. Normally this would generate an conversion via `isFromIntLit`, but when it matches with a generic match (`isGeneric`) the node is left alone and continues to have type `int` (related to #4858, but separate; since `isFromIntLit > isGeneric` it doesn't propagate). This did not cause problems on the C backend up to this point because either the compiler generated a cast when generating the C code or it was implicitly casted in the C code itself. On the JS backend however, we need to generate `int64` and `int` values differently, so we copy the integer literal and give it the matched type now instead. This is somewhat risky even if CI passes but it's required to make the times module work without [this workaround](7dfadb8b4e/lib/pure/times.nim (L219-L238)) on `--jsbigint64:on` (the default). CI exposed an issue: When matching an int literal to a generic parameter in a generic instantiation, the literal is only treated like a value if it has `int literal` type, but if it has the type `int`, it gets transformed into literally the type `int` (#12664, #13906), which breaks the tests t14193 and t12938. To deal with this, we don't give it the type `int` if we are in a generic instantiation and preserve the `int literal` type. (cherry picked from commitc73eedfe6e)
notes
Prefer moving tests to a non-js directory so that they get tested across all backends automatically. Ideally, tests/js should be reserved to code that only makes sense in js.
Note also that tests for a js specific module (e.g.: std/jsbigints) belong to tests/stdlib, (e.g.: tests/stdlib/tjsbigints.nim)