* nimRawSetjmp: support Windows
Using `_setjmp()` directly is required to avoid some rare (but very
annoying) exception-related stack corruption leading to segfaults on
Windows, with Mingw-w64 and SEH.
More details: https://github.com/status-im/nimbus-eth2/issues/3121
Also add "nimBuiltinSetjmp" - mostly for benchmarking.
* fix for Apple's Clang++
(cherry picked from commit 69aabdab80)
* fixes a possible 'javascript:' protocol exploit [backport:1.0]
* add tests
* Update tests/stdlib/trstgen.nim
* add the same logic for hyperlinks
* move the logic into a proc
Co-authored-by: narimiran <narimiran@disroot.org>
(cherry picked from commit 9338aa2497)
When creating heterogenous slices of distinct types, the compiler does
not initialize the internal type's `size` before accessing it.
This then leads to this crash message:
```
compiler/int128.nim(594, 11) `false` masking only implemented for 1, 2, 4 and 8 bytes [AssertionError]
```
This patch initializes the `size` properly, fixing the problem.
(cherry picked from commit 0213c7313b)
* Merge file size fields correctly on Windows
Merge file size fields correctly on Windows
- Merge the two 32-bit file size fields from `BY_HANDLE_FILE_INFORMATION` correctly in `rawToFormalFileInfo`.
- Fixes#19135
* Update os.nim
(cherry picked from commit 0a1049881e)
This flag has a very significant performance impact on programs compiled with --threads:on. It is also apparently not needed anymore for standard circumstances. Can we remove the config? See https://github.com/nim-lang/Nim/issues/18146#issuecomment-876802676 for discussion and perf impact. [backport:1.6]
(cherry picked from commit 77b696c2c9)
Otherwise, compiler produces broken error message - `$1` is not interpolated
`Error: The $1 type doesn't have a default value. The following fields must be initialized: importGraph.`
(cherry picked from commit 4c510d5577)
since the example code return value from global variable, instead
of first argument, the `n.len` is 1 which causes compiler crashes.
(cherry picked from commit f755e452d2)
* Fix#19052; [backport:1.6.0]
Adds a compile flag to avoid a getrandom syscall, fixing #19052.
This is neccesary when the getrandom syscall is missing, as noted in #19052, particularly in kernel versions < 3.17 when getrandom was introduced. Specifically relevant is this is missing from kernel 3.10, which is the supported kernel throughout RHEL 7 and CentOS 7, which is widely used at many organizations. Without this, versions of nim that include sysrand (i.e. versions >= 1.6.0) will not compile without modification, however with this change a compile flag may be used to fall back using /dev/urandom as done with any unknown Posix OS (preferred here as a fallback since it already supplies a cryptographically secure PRNG and existing code deals with entropy pool init, etc).
The change is placed behind a compile flag, as discussed in github ticket #19052 (summed up here):
* First, I can't seem to catch that a importc such as SYS_getrandom is declared without using it (the declared proc returns true, but compiler throws an undeclared identifier flag when referencing it).
* Second, it seemed preferable to be behaviorally explicit vs implicit when considering this is intended to be a cryptographically secure PRNG.
* Third, if I intend to compile on a kernel >= 3.17 while running the binary on at least one system < 3.17, I'll want to be able to target this without relying on a compile time determination if the getrandom syscall is available.
* Documenting compile flag for -d:nimNoGetRandom and adding changelog entry
Related to #19052 and comments in PR #19053. Also created a new changelog file since none currently exists.
Co-authored-by: Timothy Alexander <talexander@midwestlabs.com>
(cherry picked from commit dde556665a)
When assigning constant output to a seq, and then passing that static
seq to other functions that take `openArray`, the compiler may end up
producing errors, as it does not know how to convert `static[seq[T]]`
to `openArray[T]`. By ignoring the `static` wrapper on the type for
the purpose of determining data memory location and length, this gets
resolved cleanly. Unfortunately, it is relatively tricky to come up
with a minimal example, as there are followup problems from the failing
conversion, e.g., this may lead to `internal error: inconsistent
environment type`, instead of the relevant `openArrayLoc` error message.
(cherry picked from commit 490c4226a5)
Nim 1.4.x compiled the below code without error when using
`--experimental:strictFuncs`
import std/sequtils
type Foo = ref object
let foo1 = Foo()
let foo2 = Foo()
let foos = @[foo1, foo2]
let fooTuples = @[(foo1, 1), (foo2, 2)]
discard repeat(foo1, 3)
discard zip(foos, foos)
discard unzip(fooTuples)
However, since 2020-12-09, devel Nim produced errors like
/tmp/bar.nim(11, 15) template/generic instantiation of `repeat` from here
/foo/nim/pure/collections/sequtils.nim(172, 6) Error: 'repeat' can have side effects
an object reachable from 'x' is potentially mutated
/foo/nim/pure/collections/sequtils.nim(183, 15) the mutation is here
/foo/nim/pure/collections/sequtils.nim(183, 15) is the statement that connected the mutation to the parameter
This commit reverts some `proc` to `func` changes so that code that:
- calls `repeat`, `zip`, or `unzip`
- and instantiates them with types containing `ref`
can once again be compiled with `strictFuncs`. Otherwise, a user might
be forced to drop or alter their `strictFuncs` use when upgrading from
Nim 1.4.x, or when writing new code that uses these procedures (at least
for now, with the current `strictFuncs` implementation).
This commit also adds tests to assert that the remaining funcs in this
module can be compiled with `strictFuncs` when used with types
containing `ref`.
The original batch of `proc` to `func` changes in `sequtils.nim` was in
commit 6f57ebae34, which was partially reverted in 38eb021f81.
See also: https://github.com/nim-lang/Nim/issues/16305
