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
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
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>
The `warnUser` message kind is probably not the right one, but I left it
as a placeholder. It should probably at least warn if not just straight
up throw an error, was very hard to figure out what went wrong without
any indication. The hard coded 300 should possibly also be changed to
`evalTemplateLimit` or the VM call recursion limit or something.
TODO:
- [ ] test writing of .nif files
- [x] implement loading of fields in PType/PSym that might not have been
loaded
- [ ] implement interface logic
- [ ] implement pragma "replays"
- [ ] implement special logic for `converter`
- [ ] implement special logic for `method`
- [ ] test the logic holds up for `export`
- [ ] implement logic to free the memory of PSym/PType if memory
pressure is high
- [ ] implement logic to close memory mapped files if too many are open.
---------
Co-authored-by: demotomohiro <gpuppur@gmail.com>
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
Co-authored-by: Jacek Sieka <arnetheduck@gmail.com>
fixes#25265;
fixes#23453
`(addr deref (ptr object))` generated weak typedesc before, which causes
problems for old GCC versions. As a bonus, by generating a typedesc for
`deref (ptr object)`, it also fixes#23453
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.
There might be a way to do this but I couldn't find anything about it.
This is a very simple thing that goes a long way in certain situations.
Trying to avoid needing to switch to nimscript just to get:
```nim
# config.nims
import os
let srcDir = currentSourcePath.parentDir()
switch("define", &"ProjPath:\"{srcDir}\"")
```
with this change just needs:
```
# nim.cfg
d %= "ProjPath=$srcDir"
```
