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
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.)
The `hasValuelessStatics` function in `semtypinst.nim` only checked for
`tyStatic`, missing `tyTypeDesc(tyGenericParam)`. This caused
`sizeof(T)` inside a typedesc template called from a generic type's
`when` clause to error with "'sizeof' requires '.importc' types to be
'.completeStruct'".
The fix adds a check for `tyTypeDesc` wrapping `tyGenericParam`,
recognizing it as an unresolved generic parameter that needs resolution
before evaluation.
Also documents the `completeStruct` pragma in the manual.
fixes#17630
## Recursive Concept Cycle Detection
- Track (conceptId, typeId) pairs during matching to detect cycles
- Changed marker from IntSet to HashSet[ConceptTypePair]
- Removed unused depthCount field
- Added recursive concepts documentation to manual
- Added tests for recursive concepts, distinct chains, and co-dependent
concepts
## Fix Flaky `tasyncclosestall` Test
The macOS ARM64 CI jobs were failing due to a flaky async socket test
(unrelated to concepts).
The test only accepted `EBADF` as a valid error code when closing a
socket with pending writes. However, depending on timing, the kernel may
report `ECONNRESET` or `EPIPE` instead:
- **EBADF**: Socket was closed locally before kernel detected remote
state
- **ECONNRESET**: Remote peer sent RST packet (detected first)
- **EPIPE**: Socket is no longer connected (broken pipe)
All three are valid disconnection errors. The fix accepts any of them,
making the test reliable across platforms.
---------
Co-authored-by: Andreas Rumpf <araq4k@proton.me>
fixes#25312
Tuple expressions `(a, b, c)` can be either types or values depending on
if their elements are typedescs or values, this is checked by checking
if the type of the element is `tyTypeDesc`. However when an
`skGenericParam` symbol is semchecked by `semSym` it is given its own
`tyGenericParam` type rather than a `tyTypeDesc` type, this seems to be
necessary for signatures to allow wildcard generic params passed to
static constrained generic params (tested in #25315). The reason
`semSym` is called is that `semGeneric` for generic invocations calls
`matches` which sems its arguments like normal expressions.
To deal with this, an expression of type `tyGenericParam` and with a
`skGenericParam` sym is allowed as a type in the tuple expression. A
problem is that this might consider a value with a wildcard generic
param type as a type. But this is a very niche problem, and I'm not sure
how to check for this. `skGenericParam` symbols stay as idents when
semchecked so it can't be checked that the node is an `skGenericParam`
symbol. It could be checked that it's an ident but I don't know how
robust this is. And maybe there is another way to refer to a wildcard
generic param type instead of just its symbol, i.e. another kind of
node.
This also makes #5647 finally work but a test case for that can be added
after.
fixes#22305
It seems that the generic type is cached somehow so that no hooks are
instantiated for the generic type. There are only hooks for the
instantiated type. When `lambdalifting` tries to create type bounds for
the generic type, it cannot either find the instantiated hooks or
instantiate the generic hooks since it lacks `SemContext`. It can use
hooks for the instantiated type in this case
The forward declarations cause `Exception` to be inferred - also,
`llrecv` is an internal implementation detail and the type of the
received item is controlled by generics, thus the ValueError raised
there seems out of place for the generic api.
Returning or yielding from a closureiter must restore "external"
exception, but `popCurrentException` from `blockLeaveActions` was
getting in the way. So now `blockLeaveActions` doesn't emit
`popCurrentException` for returns in closureiters. I'm not a fan of this
"abstraction leakage", but don't see a better solution yet. Any input is
much appreciated.
---------
Co-authored-by: Andreas Rumpf <araq4k@proton.me>
