fixes https://github.com/nim-lang/Nim/issues/25457
Small chunks allocate memory in fixed-size cells. Each cell is
positioned at exact multiples of the cell size from the chunk's data
start, which makes it much harder to support alignment
```nim
sysAssert c.size == size, "rawAlloc 6"
if c.freeList == nil:
sysAssert(c.acc.int + smallChunkOverhead() + size <= SmallChunkSize,
"rawAlloc 7")
result = cast[pointer](cast[int](addr(c.data)) +% c.acc.int)
inc(c.acc, size)
```
See also https://github.com/nim-lang/Nim/pull/12926
While using big trunk, each allocation gets its own chunk
First performance numbers:
time tests/arc/torcbench -- YRC
true peak memory: true
real 0m0,163s
user 0m0,161s
sys 0m0,002s
time tests/arc/torcbench -- ORC
true peak memory: true
real 0m0,107s
user 0m0,104s
sys 0m0,003s
So it's 1.6x slower. But it's threadsafe and provably correct. (Lean and
model checking via TLA+ used.)
Of course there is always the chance that the implementation is wrong
and doesn't match the model.
`hashType` proc returned the same hash value from different instanced
generics types like `D[int64]` and `D[F]`.
That caused the struct type with wrong field types.
object/tuple type size check code is generated when it is compiled with
`-d:checkAbi` option.
Implements #21928
Adds a `--raw` (since thats what the original issue used, suggestions
welcome) switch which stops the jsondoc gen from rendering rst/markdown.
Implemented by making `genComment` check if it needs to return the raw
string or not. This required switching the related procs to using
`Option` to handle how `nil` values were returned before. The `nil`
returns were eventually ignored so just ignoring `none(T)` has the same
effect.
Doesn't support `runnableExamples` since jsondocs doesn't support them
either
Issue #16726 reported an internal compiler error (`semcall.nim(229, 18)
nArg != nil`) when calling `toJs` with invalid arguments. The bug has
been fixed in the current codebase but lacked a regression test.
```nim
import std/jsffi
let a = toJs(3)
let b = a.toJs(int) # Now produces: Error: type mismatch
# Previously: internal error
```
**Changes:**
- Added `tests/js/t16726.nim` to verify proper type mismatch error is
reported instead of internal compiler error
<!-- START COPILOT ORIGINAL PROMPT -->
<details>
<summary>Original prompt</summary>
>
> ----
>
> *This section details on the original issue you should resolve*
>
> <issue_title>internal error: semcall.nim(229, 18) nArg !=
nil</issue_title>
> <issue_description>### Example
> the code below should give a clean CT error, not an internal error
> ```nim
> import std/jsffi
> let a = toJs(3)
> let b = a.toJs(int)
> ```
>
> ### Current Output
> nim r -b:js main
> compiler/semcall.nim(229, 18) `nArg != nil`
>
> ### Expected Output
> proper CT error
>
> ### Additional Information
> 1.5.1 41965880ce
> </issue_description>
>
> <agent_instructions>adds a test case for it and verify it by `./koch
temp js -r test.nim` before committing</agent_instructions>
>
> ## Comments on the Issue (you are @copilot in this section)
>
> <comments>
> <comment_new><author>@ringabout</author><body>
> related:
https://github.com/nim-lang/Nim/issues/15607</body></comment_new>
> </comments>
>
</details>
<!-- START COPILOT CODING AGENT SUFFIX -->
- Fixesnim-lang/Nim#16726
<!-- START COPILOT CODING AGENT TIPS -->
---
💬 We'd love your input! Share your thoughts on Copilot coding agent in
our [2 minute survey](https://gh.io/copilot-coding-agent-survey).
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Objects containing `importc` fields without `completeStruct` fail to
compile when used as const/static. The C codegen generates "aggregate
initialization" which is invalid for opaque types.
Fixes#25405.
Nim code:
```nim
type
OpaqueInt {.importc: "_Atomic int", nodecl.} = object
ContainsImportc = object
normal: int
opaque: OpaqueInt
const c = default(ContainsImportc)
```
Resulting C code:
```c
// Invalid C - cannot aggregate-init opaque type
NIM_CONST ContainsImportc c = {((NI) 0), {}};
^^ error: illegal initializer type
```
## Solution
Fix in `ccgexprs.nim`:
1. Skip opaque importc fields when building aggregate initializers
2. Use "designated initializers" (`siNamedStruct`) when opaque fields
are present to avoid positional misalignment
```c
// Valid C:
// - opaque field is omitted and implicitly zero-initialized by C
// - other fields are explitly named and initialized
NIM_CONST ContainsImportc c = {.normal = ((NI) 0)};
```
This correctly handles the case where the opaque fields might be in any
order.
A field is considered "opaque importc" if:
- Has `sfImportc` flag
- Does NOT have `tfCompleteStruct` flag
- Either has `tfIncompleteStruct` OR is an object with no visible fields
The `containsOpaqueImportcField` proc recursively checks all object
fields, including nested objects and variant branches.
Anonymous unions (from variant objects) are handled by passing an empty
field name, which skips the `.fieldname = ` prefix since C anonymous
unions have no field name.
Note that initialization for structs without opaque importc fields
remains the same as before this changeset.
## Test Coverage
`tests/ccgbugs/timportc_field_init.nim` covers:
- Simple struct with one importc field
- Nested struct containing struct with importc field
- Variant object (case object) with importc field in a branch
- Array of structs with importc fields
- Tuple containing struct with importc field
- `completeStruct` importc types (still use aggregate init)
- Sandwich case (opaque field between two non-opaque fields)
- Fields with different C names (`{.importc: "c_name".}`, `{.exportc.}`)
- `{.packed.}` structs with opaque fields
- `{.union.}` types with opaque fields
- Deep nesting (3+ levels)
- Multiple opaque fields with renamed fields between them
Pegs raise only their own error, but the forward declaration causes an
unwanted Exception effect
* use strformat which does compile-time analysis of the format string to
avoid exceptions
* also in parsecfg
I added some precision. The first time I read this sentence, I was
confused. This applies to the above example, but it cannot be
generalized, since every array has its own range of valid indexes.
I think this change make the documentation clearer.
---------
Co-authored-by: Andreas Rumpf <araq4k@proton.me>
int128 is an array of uint32s, so while this works on little-endian
CPUs, it's completely broken on big-endian. e.g. following snippet would
fail:
const x = 0xFFFFFFFF'u32
const y = (x shr 1)
echo y # amd64: 2147483647, s390x: 0
That in turn broke float printing, resulting in miscompilation of any
code that used floats.
To fix this, we now call the aptly named castToUInt64 procedure which
performs the same cast portably.
(Thanks to barracuda156 for helping debug this.)
This code was failing to compile with `Error: unhandled exception:
semmagic.nim(247, 5) operand.kind == tyTuple tyAlias [AssertionDefect]`
```nim
import std/typetraits
type
Bar[T] = T
Foo = Bar[tuple[a: int]]
echo Foo.tupleLen
```
Fix was just making `tupleLen` skip alias types also
This is a problem on big-endian CPUs because you end up with nimvm
computing something different than Nim proper, so e.g. a const table
won't work.
I also took the liberty to replace a redundant implementation of load4
in murmurHash.
(Thanks to barracuda156 for helping debug this.)
