Reverts nim-lang/Nim#25090
It seems to cause problems for C++ and i686
```
2025-08-08T02:37:55.5976232Z c:/a/nightlies/nightlies/external/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:\Users\runneradmin\nimcache\manual_experimental_snippet_106_d\@pstd@sprivate@ssyslocks.nim.c.o:@pstd@sprivate@ssyslocks.nim.c:(.text+0x29): undefined reference to `SleepConditionVariableCS'
2025-08-08T02:37:55.5978066Z c:/a/nightlies/nightlies/external/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:\Users\runneradmin\nimcache\manual_experimental_snippet_106_d\@pthreadpool.nim.c.o:@pthreadpool.nim.c:(.text+0x26): undefined reference to `InitializeConditionVariable'
2025-08-08T02:37:55.5980101Z c:/a/nightlies/nightlies/external/mingw32/bin/../lib/gcc/i686-w64-mingw32/11.1.0/../../../../i686-w64-mingw32/bin/ld.exe: C:\Users\runneradmin\nimcache\manual_experimental_snippet_106_d\@pthreadpool.nim.c.o:@pthreadpool.nim.c:(.text+0x116): undefined reference to `WakeConditionVariable'
2025-08-08T02:37:55.5981093Z collect2.exe: error: ld returned 1 exit status
2025-08-08T02:37:55.5988564Z Error: execution of an external program failed: 'gcc.exe -o
```
- Added support for SOCKS5h (h for proxy-side DNS resolving) to
httpclient
- Deprecated `auth` arguments for `newProxy` constructors, for auth to
be embedded in the url.
Unfortunately `http://example.com` is not currently reachable from
github CI, so the tests fail there for a few days already, I'm not sure
what can be done here.
fixes#25007
```nim
proc setLengthSeqUninit(s: PGenericSeq, typ: PNimType, newLen: int, isTrivial: bool): PGenericSeq {.
compilerRtl.} =
```
In this added function, only the line `zeroMem(dataPointer(result,
elemAlign, elemSize, newLen), (result.len-%newLen) *% elemSize)` is
removed from `proc setLengthSeqV2` when enlarging a sequence.
JS and VM versions simply use `setLen`.
Reworked closureiter transformation.
- Convolutedly nested finallies should cause no problems now.
- CurrentException state now follows nim runtime rules (pushes and pops
appropriately), and mimics normal code, which is somewhat buggy, see
#25031
- Previously state optimization (removing empty states or extra jumps)
missed some opportunities, I've reimplemented it to do everything
possible to optimize the states. At this point any extra states or jumps
should be considered a bug.
The resulting codegen (compiled binaries) is also slightly smaller.
**BUT:**
- I had to change C++ reraising logic, see expt.nim. Because with
closure iters `currentException` is not always in sync with C++'s notion
of current exception. From my tests and understanding of C++ runtime
there should not be any problems, but I'm only 99% sure :)
- I've reused `nfNoRewrite` flag in one specific case during the
transformation. This flag is also used in term-rewriting logic. Again,
99% sure, these 2 scenarios will never intersect.
Docs are routinely compiled on a different OS so often don't reflect
reality of CT-conditionals.
I bet there's a few of other places like this in the stdlib.
todo: We can also give a deprecation message for `ltPtr`/`lePtr`
matching for cstring in `magicsAfterOverloadResolution`
follow up https://github.com/nim-lang/Nim/pull/24942
explaining why the result may not be so surprising. Clean-up of stray
whitespace and insert of missing "in" along for the ride.
It's just not always faster or slower than `Table`. The difference
depends upon many factors such as (at least!): A) how much (if anything
- for `int` keys it is nothing) hash-comparison before `==` comparison
saves B) how much resizing happens (which may even vary from run to run
if end users are allowed to provide scale guess input), C) how much
comparison happens at all (i.e., table density), D) how much space/size
matters - like how close to a specific deployment "available" cache size
the table is.
If we want, we could add a sentence suggesting performance fans also try
`Table`, but the kind of low-level nature of the explanation strikes me
as already along those lines.
Fixes#24895
- Remove all bio handling
- Remove all `sendPendingSslData` which only seems to make things work
by chance
- Wrap the client socket on `acceptAddr` (std/net does this)
- Do the SSL handshake on accept (std/net does this)
The only concern is if addWrite/addRead works well on Windows.
On windows, `HANDLE` type values are converted to `syncio.FileHandle` in
`lib/std/syncio.nim`, `lib/pure/memfiles.nim` and `lib/pure/osproc.nim`.
`HANDLE` type is `void *` on Windows and its size is larger then `cint`.
https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types
This PR change `syncio.FileHandle` type so that converting `HANDLE` type
to `syncio.FileHandle` doesn't lose bits.
We can keep `FileHandle` unchanged and change some of parameter/return
type from `FileHandle` to an type same size to `HANDLE`, but it is
breaking change.
ref https://github.com/nim-lang/Nim/issues/24764
To keep destructors injected consistently, we need to transform `mAsgn`
properly into `nkSinkAsgn` and `nkAsgn`. This PR is the first step
towards overhauling hook injections.
In this PR, hooks (except mAsgn) are treated consistently whether it is
resolved in matching or instantiated by sempass2. It also fixes a
spelling `=wasMoved` to its normalized version, which caused no
replacing generic hook calls with lifted hook calls.
implements https://github.com/nim-lang/RFCs/issues/557
It inserts defect handing into a bare except branch
```nim
try:
raiseAssert "test"
except:
echo "nope"
```
=>
```nim
try:
raiseAssert "test"
except:
# New behaviov, now well-defined: **never** catches the assert, regardless of panic mode
raiseDefect()
echo "nope"
```
In this way, `except` still catches foreign exceptions, but panics on
`Defect`. Probably when Nim has `except {.foreign.}`, we can extend
`raiseDefect` to foreign exceptions as well. That's supposed to be a
small use case anyway.
`--legacy:noPanicOnExcept` is provided for a transition period.
fixes#24837
I really wanted to name the variable just `stream` and leave `defer:
...` and `result =...` out, but the compiler says the variable is
redefined, so this is the form.
This change adds `withValue` templates for the `Table` type that are
able to operate on immutable table values -- the existing implementation
requires a `var`.
This is needed for situations where performance is sensitive. There are
two goals with my implementation:
1. Don't create a copy of the value in the table. That's why I need the
`cursor` pragma. Otherwise, it would copy the value
2. Don't double calculate the hash. That's kind of intrinsic with this
implementation. But the only way to achieve this without this PR is to
first check `if key in table` then to read `table[key]`
I brought this up in the discord and a few folks tried to come up with
options that were as fast as this, but nothing quite matched the
performance here. Thread starts here:
https://discord.com/channels/371759389889003530/371759389889003532/1355206546966974584
- Allows using with `--experimental:strictFuncs`
- `{.cast(noSideEffect).}:` inside the proc was required to mutate
`s.len`, same as used in `newSeqImpl`.
- Removed now unnecessary `noSideEffect` casts in `system.nim`
-
Closes#24811
Co-authored-by: ringabout <43030857+ringabout@users.noreply.github.com>
- `system.substr` now uses `copymem` when available, introducing a small
template for nimvm detection (#12517#12518)
- Docs are updated to clarify behaviour on out-of-bounds input
- Runnable examples cover more edge cases and do not repeat between
overloads
- Docs now explain the difference between overloads
What bothers me is that the `substr*(a: openArray[char]): string =`
which was added by @beef331 is practically an implementation of #14810,
which is just a conversion from `openArray` to `string` but somehow it
ended up being a `substr` overload, even though its behaviour is totally
different, _the "substringing" is performed by a previous step_
(conversion to openArray) and the bounds are not checked. I'm not sure
it's that great for overloads to differ in subtle ways so much.
What are the cases that `substr` covers now, that prohibit renaming it
to `toString` (or something like that)?
Multiple replacements based on character sets in a single pass. Useful
for string sanitation. Follows existing `multiReplace` semantics.
Note: initially copied the substring version logic with a `while` and a
named block break, but Godbolt showed it had produced slightly larger
assembly using higher registers than the final version.
- [x] Tests
- [x] changelog.md
Follow up https://github.com/nim-lang/Nim/pull/19512
ref https://github.com/nim-lang/Nim/issues/24794
Otherwise, `/Users/blue/Desktop/Nim/lib/system/mm/malloc.nim(4, 1)
Error: redefinition of 'allocImpl'; previous declaration here:
/Users/blue/Desktop/Nim/lib/system/memalloc.nim(51, 8)`
In `proc allocImpl*(size: Natural): pointer {.noconv, rtl, tags: [],
benign, raises: [].}`, `rtl` means it is an `importc` function instead
of a proc forward decl.
Async SSL socket SIGSEGV's sometimes when calling socket.close() while
send/recv. The issue was found here
https://github.com/nitely/nim-hyperx/pull/59.
Possibly related: #24024
This can occur when closing the socket while sending or receiving,
because `socket.sslHandle` is freed. The sigsegv can also occur on calls
that require `socket.bioIn` or `socket.bioOut` because those use
`socket.sslHandle` internally. This PR checks sslHandle is set before
doing any operation that requires it.
fixes#24772
The old implementation was said to copied from Windows SDK,
but you can find the newer SDK's definition is updated and the sign is
reversed compared to the old.
Also, `__builtin_nanf("")` is used if available,
which is more efficient than previous (In x86_64 gcc, latter produces
32B code but former just 8B).
Without this fix, trying to use `scanTuple` in a generic proc imported
from a different module fails to compile (`undeclared identifier:
'scanf'`):
```nim
# module.nim
import std/strscans
proc scan*[T](s: string): (bool, string) =
s.scanTuple("$+")
```
```nim
# main.nim
import ./module
echo scan[int]("foo")
```
Workaround is to `export scanf` in `module.nim` or `import std/strscans`
in `main.nim`.
fixes#24664
```nim
proc main() =
for i in 0..1:
var s = "12345"
s.add s
echo s
main()
```
In the given example, `add` contains two steps: `prepareAdd` and
`appendString`. In the first step, a new buffer is created in order to
store the final doubled string. But it doesn't copy the null terminator,
neither zeromem the left unused spaces. It causes a problem because
`appendString` will copy itself which doesn't end with `\0` properly so
contaminated memory is copied instead.
```
var s = 12345\0
prepareAdd:
var s = 12345xxxxx\0
appendString:
var s = 1234512345x
```
ref https://github.com/nim-lang/Nim/pull/24686
With this PR
```nim
import std/streams
proc foo() =
var name = newStringStream("2r2")
raise newException(ValueError, "sh")
try:
foo()
except:
discard
echo 123
```
this example no longer leaks
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
fixes#24673
The problem is that there is no way to distinguish `cint`, `cint`, etc
ctypes with Nim types. So `when T is cint | clong | clonglong:` is true
for types derived from `int`, `int32` and `int64`. In this PR, it fixes
the branch to avoid erros for `Natural`
