* I don't care about observable stores
* enforce explicit initializations
* cleaner code for the stdlib
* stdlib: use explicit initializations
* make tests green
* algorithm.nim: set result explicitly
* remove out parameters and bring the PR into a mergable state
* updated the changelog
* fix#14142: no more clash with: import os + use of existsDir/dirExists/existsFile/fileExists/findExe in config.nims
* remove a comment
* Revert "fixes the regression #12860 caused; hotfix"
This reverts commit 3d2459bdc0.
* Revert "Undefine `paramCount` & `paramStr` in nimscript.nim for *.nims (#12860)"
This reverts commit d38853c504.
* noNimScript => noWeirdTarget + noNimJs
* json custom serialization; application for strtabs
* serialize using nesting
* make toJson more feature complete
* add since
* Revert "Improve JSON serialisation of strtabs (#14549)"
This reverts commit 7cb4ef26ad.
* better approach via mixin
* toJson, jsonTo
* fix test
* address comments
* move to jsonutils
* doc
* cleanups
* also test for js
* also test for vm
Per SSL_get_error(3):
The current thread's error queue must be empty before the TLS/SSL I/O
operation is attempted, or SSL_get_error() will not work reliably.
There has been records of not clearing the error queue causing weird SSL
errors when there shouldn't be any, see:
https://github.com/openssl/openssl/issues/11889
The error we're looking for is "certificate verify failed". The routine
that reports this will be different between openssl versions, so it
makes no sense to track the routine name as well.
* tfdleak_multiple: introduce stress tester for tfdleak
Imported from #14548 and tweaked for consumption by testament.
This test seems to be really good at bringing out the flakyness of
tfdleadk.
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
* tfdleak: increase accuracy of the test on Windows
This commit implements a new testing strategy for Windows:
1. We duplicate the handle that will be tested and enable inheritance.
This duplicate will serve as a reference handle.
2. In addition to checking whether the handle is valid, we also verify
whether the handle is the same as the reference. This gives us
complete certainty on whether the handle in question is inherited
from the parent.
A side effect is that this uses Windows 10+ APIs. But since
this is just for the test, we don't have to be picky about it.
Ideally we would want to do something like this for other POSIX-based
system, but most of them lack a facility to do this, and as of writing
there isn't any false positive for them, so we won't need the additional
checks.
MemFile.fHandle will also no longer be tested, as this handle defaults
to being invalid.
Co-authored-by: Timothee Cour <timothee.cour2@gmail.com>
