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>
* move io out of system
* fix tests
* fix tests
* next step
* rename to syncio
* rename
* fix nimscript
* comma
* fix
* fix parts of errors
* good for now
* fix test
* add [1..2] for JArray
* fix BackwardsIndex to int
* fix for BackwardsIndex
* fix for assert node kind check
* fix variable name
* Update lib/pure/json.nim
* fix for when x.a is BackwardsIndex
Co-authored-by: itsumura-h <dumblepy@mail.com>
Co-authored-by: Dominik Picheta <dominikpicheta@googlemail.com>
* CIs: attempt to use csources_v1
* also updated the BSDs
* also updated azure pipelines
* std modules should not itself use the 'std/' import dir...
* compiler has to be careful with std/ for v1 booting
* json custom serialization; application for strtabs
* serialize using nesting
* make toJson more feature complete
* add since
* Revert "Improve JSON serialisation of strtabs (#14549)"
This reverts commit 7cb4ef26ad.
* better approach via mixin
* toJson, jsonTo
* fix test
* address comments
* move to jsonutils
* doc
* cleanups
* also test for js
* also test for vm
* Error -> Defect for defects
The distinction between Error and Defect is subjective,
context-dependent and somewhat arbitrary, so when looking at an
exception, it's hard to guess what it is - this happens often when
looking at a `raises` list _without_ opening the corresponding
definition and digging through layers of inheritance.
With the help of a little consistency in naming, it's at least possible
to start disentangling the two error types and the standard lib can set
a good example here.
* base `parseEnum` on a case statement, fixes#14030
* apply simplifactions / clean up, remove `norm` node, use strVal
* export `normalize` in json.nim
* cmp using nimIdentNormalize, error at CT if ambiguous enum found
`nimIdentNormalize` provided by @cooldome.
We track all names of the branches we have created so far and error if
a duplicate is found.
Dummy change to make github react...
* fix docstring of `nimIdentNormalize`
* make `typ` arg `typedesc`, add lineinfo, call norm. only once
