why ?
- We already have an emit that does the same thing
- The name asm itself is a bit confusing, you might think it's an alias
for asm.js or something else.
- The asm keyword is used differently on different compiler targets (it
makes it inexpressive).
- Does anyone (other than some compiler libraries) use asm instead of
emit ? If yes, it's a bit strange to use asm somewhere and emit
somewhere. By making the asm keyword for js target deprecated, there
would be even less use of the asm keyword for js target, reducing the
amount of confusion.
- New users might accidentally use a non-universal approach via the asm
keyword instead of emit, and then when they learn about asm, try to
figure out what the differences are.
see https://forum.nim-lang.org/t/10821
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* adding new system module sysexitprocs and including system exit procedures when registering exit handlers defined in userland
* fixing failing tests and adding initialization guard to handle cases where the module's global init logic isn't invoked first as is the case with some gc implementaions
* js backend shouldn't try to invoke actual system exit procs
* fixing formatting in sysexitprocs.nim
* 256 was too much - my max number of plugins in my engine is 64 and I require two hooks per runtime it looks like with tls emulation turned off, so for my purposes 128 should be sufficient
* so atExit should be enough here, can get rid of all the extra cruft I had added on top since I didn't realize atExit already provided a stack
* done being cute - since newruntime prevents correct cpp codegen for object variants apparently and breaks tests if I try to use std/exitprocs, ddSysExitProc is just going into both modules. Since system doesn't include system/io, polluting system with it doesn't make sense either... at least it is only importc'd when it is required in either module and we don't have to have any weird when defined(nimOwnedEnabled) with a comment explaining why
* deinitializing locks at program exit
* deinitLock shouldn't be called for js backend I guess...
* I suppose this is the best way to detect the
ewruntime option
* I guess I need these guards here too...
* fixing merge conflict
* fix#14475; make unittest work with -d:nodejs
* fixup
* fixup
* disable inim, delaunay which failed after unittest.require got fixed
* re-enable tests that have been fixed
