* [ performance ] a much faster implementation of unpack
* [ fix ] partiality error in Hangman test
* [ test ] add some documentation to the unpack test case
* [ test ] fix expected output of unpack test
* Emit warning for fixities with no export modifiers
This is to help update all the existing code to program with explicit
fixity export directives in preparation for the behavioral change where
they will become private by default.
This is required due to `Lazy` now being a reserved compiler primitive.
N.B. This may also break other dependencies and/or tools. Notably stuff
outwith the Idris2 upstream. There's been some discussion in #2987.
* RefC backend improvements
1. OnCollect had the wrong number of arguments. The code creator expects
3 arguments, but onCollect in prim.h expected 4 arguments. The first of which
was an erased arguments. That is now fixed.
2. OnCollect did not call `newReference` when creating a new reference to the pointer
and the freeing function
3. OnCollect and OnCollectAny still had a spurious printf statement
Those issues have been fixed, the test case can be found in
tests/refc/garbageCollect
4. The IORef mechanism expects that the %World token will be passed around
consistently. This is not the case. States in Control.App make use of
IORefs, but the function created from Control.App.prim_app_bind
had the world token erased to NULL.
Now, IORefs are managed using a global variable,
IORef_Storage * global_IORef_Storage;
referenced in cBackend.h, defined in the created .c file, and set to NULL
in main();
5. While multithreading and forking is still not supported, compiling a program
that makes use of Control.App demands a C implementation of prim_fork.
Files support/refc/threads.c and support/refc/threads.h provide a
dummy implementation for it, so that Control.App programs compile and run.
A test for these 2 issues is given in tests/refc/issue2424
* format changes
to make the linter happy
* format changes
to make the linter happy
* format changes
to make the linter happy
* spelling mistake braket -> bracket
Co-authored-by: Volkmar Frinken <volkmar@onutechnology.com>
