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
* Fixed `strictFuncs` support for `std/pegs`
Enabled `std/pegs` in the `strictFuncs` import test.
Fixes#18057Fixes#16892
See #18111
* Rebased from `devel`
* Conditionally compile `std/pegs` in `koch`
This is for supporting `csources` bootstrap.
Co-authored-by: quantimnot <quantimnot@users.noreply.github.com>
