improvements to addInt and $ for integer types

[timotheecour]

• major simplifications to $ and addInt for integer types: instead of hardcoding the logic in the compiler (spread over a whopping > 10 files, with magics, compilerProcs, etc), all the logic is now handled in 1 place for addInt (digitsutils) and 1 place for $: (dollars)
• fix $ is wrong for unsigned types (eg uint8) in js #18591: $ and addInt for js in runtime now works correctly by calling js x + "" in js backend (consistent with what console.log would return), instead of producing wildly inconsistent and non-sensical results
• addInt now supports unsigned integer types, avoiding the slower foo.add $x which allocates (see 3x faster digits10 via binary search (speeds up $ for numbers) #18324 which has benchmarks showing, unsurprisingly, that those allocations are costly)
• improve implementation of toLocation (avoid allocations, and avoid when declared)
• avoid allocations in addQuoted for unsigned ints

note:

splitting these tasks in separate PRs would complicate things a lot in this case, due to a number of constraints (in particular some bugs in csources_v1 that prevent certain obvious things from working)

[timotheecour]

PTAL

[timotheecour]

@Araq ping on this before this bitrots

[Araq]

Nim devel cannot compile Nim 1.4 or earlier because you removed the magics. This removes more magics and so the problem will be worse. Would be nice if we could think of a solution for this problem; apart from that, I like the changes.

[timotheecour]

indeed, after #18531, nim devel can't compile 1.4.0:

dollars.nim(27, 36) Warning: unknown magic 'FloatToStr' might crash the compiler [UnknownMagic]
dollars.nim(27, 6) Error: implementation of 'dollars.$(x: float)' expected

note that even before #18531, nim devel can't compile 1.2.0:

system.nim(164, 8) Warning: unknown magic 'DefinedInScope' might crash the compiler [UnknownMagic]
system.nim(163, 6) Error: implementation of 'system.declaredInScope(x: untyped)' expected

requiring that nim devel can compile prior versions prevents much needed simplifications though; plenty of magics (eg abs) should in fact be turned into regular procs (and in some cases vmops), which avoids spreading the implementation over all backends (c, js, vm); it wouldn't be so bad if magics implementation were self-contained, but they're spread over many places, eg in this PR the magic implementations I removed were spread over 10 files and probably can't be simplified if I keep them in (likewise, implementation of $float was spread over > 10 files before #18531)

And, because compilining 1.4 from devel is not tested in CI, other PRs further break this (eg #11955 which introduces a new compilerProc raiseFieldError2).

Note that you already have the means to programmatically find the right nim version with which to build any prior nim version >= #17815 by checking in the bootstrap url+commit hash, and, with nimdigger (#18119), we can build any nim version >= v0.12.0

In short, I'd rather keep simplifying the compiler than require that new nim versions be able to build older nim versions, which adds un-necessary complexity.

[arnetheduck]

In short, I'd rather keep simplifying the compiler than require that new nim versions be able to build older nim versions, which adds un-necessary complexity.

the bare minimum standard here tends to be that each version of the compiler can be compiled by the previous version of the compiler - this allows people with a working compiler to upgrade it to the next version without leaving the language - applying that strategy recursively one can reach any released version from any earlier version.

It's somewhat surprising that compiling older versions should be a problem if basic backwards compatibility strategies are adhered to (ie deprecating instead of removing being the most simple one), but it's of course easier to not think about this.

[timotheecour]

the bare minimum standard here tends to be that each version of the compiler can be compiled by the previous version of the compiler

nim 1.4 can compile nim devel, both before and after this PR.

It's somewhat surprising that compiling older versions should be a problem if basic backwards compatibility strategies are adhered to (ie deprecating instead of removing being the most simple one),

this doesn't impact backward compatibility for user code

[timotheecour]

ping @Araq

[Araq]

Keep the magics, I enjoy being able to compile 1.4 with Nim devel. (This implies the other removed magics should be brought back too.)

[timotheecour]

=> #18708

[timotheecour]

Keep the magics

@Araq done, PTAL