* CIs: attempt to use csources_v1
* also updated the BSDs
* also updated azure pipelines
* std modules should not itself use the 'std/' import dir...
* compiler has to be careful with std/ for v1 booting
(cherry picked from commit a9b62de895)
* Remove the use of usrToCell in gcMark [backport:1.2]
Recently, we've discovered a GC crash resulting from inlining of
the memory allocation procs that allowed the compiler to avoid
maintaining any references to the "user pointer" on the stack.
Instead, a "cell pointer" appeared there and all field accesses
were performed with adjusted offsets. This interfered with the
ability of the GC to mark the correct cell in the conservative
stack scans which lead to premature collection of objects.
More details here:
af69b3ceae
This commit closes another theoretical loophole that may lead to
the same problem. If a short proc is accessing both the object and
its reference count in a short sequence of instructions, the compiler
may be enticed to reduce the number of registers being used by storing
only a single pointer to the object and using offsets when reading
and writing fields. A perfectly good strategy would be to store only
the cell pointer, so the reference count updates can be performed
without applying offsets. Accessing the fields of the object requires
offsets anyway, but these can be adjusted at compile-time without any
loss. Following this strategy will lead to the same problem of marking
a wrong cell during the conservative stack scan, leading to premature
collection.
The problem is avoided by not using `usrToCell` in `gcMark`. Since
the cell discovery logic can already handle interior pointers, the
user pointers don't need to be adjusted for the GC to function correctly.
(cherry picked from commit 3b47a689cf)
This is taken from:
af69b3ceae
Full original comment:
This is to avoid heavy inlining happening when two allocation calls
would occur shortly after each other.
This inlining would sometimes be accompanied with an optimisation
as the compiler is able to see that cellToUsr ending the first
allocation call is shortly followed by an usrToCell call. The
pointer arithmetic is redundant and the compiler can eliminate it,
leaving only the cell address in a register (and later the stack)
instead of the actual pointer to the user data, as one would expect.
This combined with a GC collect cycle will cause the stack scan to
only notice the cell address, which is of no good due to a usrToCell
in the gcMark call which shifts that address to an adjacent cell.
This means that the actual cell of importance will not get marked
and thus cause a premature collection of that cell. BOOM.
(cherry picked from commit 40093b4a93)
* fixes#11225; generic sandwich problems; [backport:1.2]
* progress
* delegating these symbols must be done via 'bind'
(cherry picked from commit 2f213db7ee)
Follow up of 5dc544e1f5
After updating windeps.zip, it appears that Windows' build was
unchanged. As it turns out, cacert.pem is not set for packaging by the
compiler package manifest.
This commit add cacert.pem to the Windows package.
(cherry picked from commit d35f366d6f)
* fixes#17033 [backport:1.4]
* make test robust against stdlib gensym things
* cleanup assertions.nim to make topt_no_cursor easier to get right
(cherry picked from commit f32ffb6ed8)
* Remove declPragmas from lambdas [backport:1.0]
* add test for exportc
* fix test
* fix align, nodecl -> noinit
(cherry picked from commit 49b64e8dc7)
* basic cleanups regarding SSL handling
* enabled certificate checking on Windows
* updated the SSL test
* quoting helps
(cherry picked from commit abac35e743)
