fixes#24844
it may not be used in other places except in `genTraverseProc`,
we have to generate a `typedesc` for this case, not a weak `typedec`
(cherry picked from commit a77d1cc6c1)
fixes#24847
Object constructors call `fillObjectFields` when a field inside the
constructor does not have a location, however when the field is from a
base type this does not process it. Now `fillObjectFields` also calls
itself for the base type to fix this but not sure if this is a good
solution as `fillObjectFields` is used in other places too.
(cherry picked from commit a625fab098)
fixes#24705
```nim
proc xxx(v: static int) =
echo v
xxx(10)
xxx(20)
```
They are mangled as `_ZN14titaniummangle7xxx_s10E` and
`_ZN14titaniummangle7xxx_s20E` with `--debugger:native`. Static
parameters are prefixed with `_s` to distinguish simple cases like
`xxx(10, 15)` and `xxx(101, 5)` if `xxx` supports two `static[int]`
parameters
(cherry picked from commit c452275e29)
fixes#24725
`lacksMTypeField` doesn't take the base types into consideration. And
for ` {.inheritable, pure.}`, it shouldn't generate a `m_type` field.
(cherry picked from commit e449813c61)
fixes#18896fixes#20886
```nim
type
PFile {.importc: "FILE*", header: "<stdio.h>".} = distinct pointer
# import C's FILE* type; Nim will treat it as a new pointer type
```
This is an excerpt from the Nim manual. In the old Nim versions, it
produces a void pointer type instead of the `FILE*` type that should
have been generated. Because these C types tend to be opaque and adapt
to changes on different platforms. It might affect the portability of
Nim on various OS, i.e. `csource_v2` cannot build on the apline platform
because of `Time` relies on Nim types instead of the `time_t` type.
ref https://github.com/nim-lang/Nim/pull/18851
(cherry picked from commit 8be82c36c9)
based on #24127
Needs some tweaks to replace the other `struct` type generations, e.g.
seqs, maybe by exposing `BaseTypeKind` as a parameter. C++ and
codegenDecl etc seem like they are going to need attention.
Also `Builder` should really be `distinct string` that one has to call
`extract` on, but for this to be optimal in the current codegen, we
would need something like:
```nim
template buildInto(s: var string, builderName: untyped, body) =
template `builderName`: untyped = Builder(s)
body
buildInto(result, builder):
builder.add ...
```
but this could be a separate PR since it might not work with the
compiler. The possibly-not-optimal alternative is to do:
```nim
template build(builderName: untyped, body): string =
var `builderName` = Builder("")
body
extract(`builderName`)
result = build(builder):
builder.add ...
```
where the compiler maybe copies the built string but shouldn't.
---------
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
…instantiations (C/C++ backend)
AFAIK, #22802 expanded `noinit`'s utility by allowing the pragma to be
attached to types (thanks @jmgomez !).
I suggest broadening the scope a bit further: try to avoid `nimZeroMem`s
on a type level beyond imported C/C++ types[^1], saving us from
annotating the type instantiations with `noinit`.
If this change is deemed acceptable, I will also adjust the docs, of
course.
Adding tests for this change seems a bit problematic, as the effect of
this type annotation will be to work with uninitialized memory, which
*might* match 0 patterns.
[^1]: "complex value types" as already defined here:
94c5996877/compiler/cgen.nim (L470-L471)
the function name extension encoded by paths could be useful for
debugging where the function is from
Before:
```js
function newSeq_33556909(len_33556911)
```
After:
```js
function newSeq__system_u2477(len_p0)
```
**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>
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.
* [C++] Member pragma RFC #530
rebase devel
* changes the test so `echo` is not used before Nim is init
* rebase devel
* fixes Error: use explicit initialization of X for clarity [Uninit]
* alternative to #22219; adds a pointer wrapper for T destructor
* clean up and add comments
* Update compiler/ccgtypes.nim
* tidy up
* fixes comments
* fixes cpp
* fixes cpp
* WIP: removal of seq spam in generated C/C++ output and Module.typeStack cleanup
* removal of seq spam in generated C/C++ output and Module.typeStack cleanup
