fixes#21441
When compiling for JS, nimscript config files have both `defined(js)`
and `defined(nimscript)` be true at the same time. This is required so
that the nimscript config file knows the current compilation is for the
JS backend. However the system module doesn't account for this in some
cases, defining JS-specific code or not defining nimscript-specific code
when compiling such nimscript files. To fix this, have the `nimscript`
define take priority over the `js` one.
This fixes crashes in some specific network configurations (as
`cstringArrayToSeq` is used extensively in `nativesockets`).
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
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>
**TODO**
- [x] fixes changelog
With the new option `nimPreviewVtables`, `methods` are confined in the
same module where the type of the first parameter is defined
- [x] make it opt in after CI checks its feasibility
## In the following-up PRs
- [ ] in the following PRs, refactor code into a more efficient one
- [ ] cpp needs special treatments since it cannot embed array in light
of the preceding limits: ref
https://github.com/nim-lang/Nim/pull/20977#discussion_r1035528927; we
can support cpp backends with vtable implementations later on the
comprise that uses indirect vtable access
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
fixes#22286
ref https://forum.nim-lang.org/t/10642
For backwards compatibilities, we might need to keep the changes under a
preview compiler flag. Let's see how many packags it break.
**TODO** in the following PRs
- [ ] Turn the `var T` destructors warning into an error with
`nimPreviewNonVarDestructor`
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
Per manual, `panics:on` affects _only_ `Defect`:s - thus `sysFatal`
should not redirect any other exceptions.
Also, when `sysFatal` is used in `nimPanics` mode, it should use regular
exception handling pipeline to ensure exception hooks are called
consistently for all raised defects.
fixes#22898
In these cases, the tables/sets are clears or elements are deleted from
them. It's reasonable to suppress warnings because the value is not
accessed anymore, which means it's safe to ignore the warnings.
fixes#22883
…eDefault` warnings
avoid issues mentioned by https://forum.nim-lang.org namely, it
allocated unnecessary stack objects in the loop
```c
while (1)
{
tyObject_N__8DSNqSGSHBKOhI8CqSgAow T5_;
nimZeroMem((void *)(&T5_), sizeof(tyObject_N__8DSNqSGSHBKOhI8CqSgAow));
eqsink___test4954_u450((&(*t_p0).data.p->data[i].Field1), T5_);
}
```
It might be more efficient in some cases
follow up https://github.com/nim-lang/Nim/pull/21821
fixes#22856
`-d:nimStrictDelete` is introduced in 1.6.0, which promised to be
enabled in the coming versions. To keep backwards incompatibilities, it
also extends the feature of `-d:nimAuditDelete`, which now mimics the
old behaviors.
Theoretical Benefits / Plans:
- Typed assembler-like language.
- Allows for a CPS transformation.
- Can replace the existing C backend by a new C backend.
- Can replace the VM.
- Can do more effective "not nil" checking and static array bounds
checking.
- Can be used instead of the DFA.
- Easily translatable to LLVM.
- Reasonably easy to produce native code from.
- Tiny memory consumption. No pointers, no cry.
**In very early stages of development.**
Todo:
- [x] Map Nim types to IR types.
- [ ] Map Nim AST to IR instructions:
- [x] Map bitsets to bitops.
- [ ] Implement string cases.
- [ ] Implement range and index checks.
- [x] Implement `default(T)` builtin.
- [x] Implement multi string concat.
- [ ] Write some analysis passes.
- [ ] Write a backend.
- [x] Integrate into the compilation pipeline.
* fixes newStringUninitialized; implement `newStringUninitialized`
* add a simple test case
* adds a changelog
* Update lib/system.nim
* Apply suggestions from code review
rename to newStringUninit
