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>
While `a.push.apply(a, b)` is better for performance than the previous
`a = a.concat(b)` due to the fact that it doesn't create a new array,
there is a pretty big problem with it: depending on the JS engine, if
the second array is too long, it can [cause a
crash](https://tanaikech.github.io/2020/04/20/limitation-of-array.prototype.push.apply-under-v8-for-google-apps-script/)
due to the function `push` taking too many arguments. This has
unfortunately been what the codegen produces since 1.4.0 (commit
707367e1ca).
So string addition is now moved to a compilerproc that just uses a `for`
loop. From what I can tell this is the most compatible and the fastest.
Only potential problem compared to `concat` etc is with aliasing, i.e.
adding an array to itself, but I'm guessing it's enough that the length
from before the iteration is used, since it can only grow. The test
checks for aliased nim strings but I don't know if there's an extra
protection for them.
fixes#25008
It seems that `semOverloadedCall` evaluates the same node twice using
`tryConstExpr` in order for `efExplain` to print all the diagnostic
output. The problem is that `tryConstExpr` has side effects, i.e., it
changes the slot index of variables after VM execution.
fixes#25123; fixes#11862
follow up https://github.com/nim-lang/Nim/pull/24442
ref https://github.com/nim-lang/Nim/pull/24441
> To fix this, fields from inactive branches are now detected in
semmacrosanity.annotateType (called in fixupTypeAfterEval) and marked to
prevent the codegen of their assignments. In
https://github.com/nim-lang/Nim/pull/24441 these fields were excluded
from the resulting node, but this causes issues when the node is
directly supposed to go back into the VM, for example as const values. I
don't know if this is the only case where this happens, so I wasn't sure
about how to keep that implementation working.
Object variants fields coming from inactive branches from VM are now
flagged `nfPreventCg`. We can ignore them, as done by the C backends.
fixes#25208
```nim
type Conf = object
val: int
const defaultConf = Conf(val: 123)
static:
var conf: Conf
conf = defaultConf
```
```nim
# opcLdConst is now always valid. We produce the necessary copy in the
# assignments now:
```
A `opcLdConst` is generated for `defaultConf` in `conf = defaultConf`.
According to the comment above, we need to handle the copy for
assignments of `opcLdConst`
fixes#25046
```nim
proc makeiter(v: string): iterator(): string =
return iterator(): string =
yield v
# loops
for c in makeiter("test")():
echo "loops ", c
```
becomes
```nim
var temp = makeiter("test")
for c in temp():
echo "loops ", c
```
for closures that might have side effects
fixes#25205fixes#14873
```nim
type
SysLockObj {.importc: "pthread_mutex_t", pure, final,
header: """#include <sys/types.h>
#include <pthread.h>""", byref.} = object
when defined(linux) and defined(amd64):
abi: array[40 div sizeof(clong), clong]
```
Before this PR, in refc, `resetLoc` generates field assignments for each
fields of `importc` object. But the field `abi` is not a genuine field,
which doesn't exits in the struct. We could use `zeroMem` to reset the
memory if not leave it alone
fixes#24760
I tried `incl` `tfHasAsgn` to nontrivial assignment, but that solution
seems to break too many things. Instead, in this PR, `passCopyToSink`
now checks nontrivial assignment
