Github Action status are based on workflows, not jobs. When #1645 was
merged, it changed multiple workflows into 1 workflow with multiple
jobs. This meant several badges on the README were now linking to
workflows which don't exist. This change makes a badge for the new
single workflow which does exist.
While it would probably be better to have statuses per job, I think the
only way to achieve that would be with an extra action like
https://github.com/marketplace/actions/bring-your-own-badge. So I'll
just stick with this minor fix for now.
Convert `App.Control.Exception` interface to an alias to `HasErr`.
Probably `Exception` interface need to be deprecated or removed.
Note similar problem exists with `PrimIO` calling `PrimIO, Exception`,
also need to be fixed.
Fix this scenario:
```
throwBoth : Has [Exception String, Exception Int] es => App es ()
throwOne : Has [Exception Int] es => App es Int
throwOne {es} = handle {err = String} {e = es} throwBoth (\r => pure 1) (\e => pure 3)
```
With this commit it works, before this commit it failed with:
```
Error: While processing right hand side of throwOne. Can't find an implementation for Exception Int (String :: es).
TestException.idr:8:48--8:57
|
8 | throwOne {es} = handle {err = String} {e = es} throwBoth (\r => pure 1) (\e => pure 3)
| ^^^^^^^^^
```
We inline some holes when solving them if they pose no risk to breaking
sharing, since this can speed up a few things. But if the hole was
originally a user name, we might want to refer to it, and inlining it
menas we can't since it won't be saved to disk.
A record field can add two names to the context, a UN-name and an
RF-name. The docstring is now saved for both names, so that it can
always be found when one of the names can be resolved.
Previously the docstring was only saved for the UN-name which led to the
docs missing when looking up the (.fieldName) version, e.g. when listing
docs for the record type.
The (implicitly added) "."-prefix when calling `isOpName` with an RF-name
leads to `isOpName` always returning true (which is correct in most
cases, where the RF is displayed as such). In case of the docs however,
we only show the name root and thus should check the "real" name of the
field (without the added dot in the beginning).
The `Decl` annotation should go directly on the name-type part. This
automatically fixes the `Decl` annotation being skipped, when no
docstring is found.
This allows for cross-flake testing of content-addressible nix derivations without
affecting other users of the flake (which would be the cases if CA-drvs would be
hard-coded upstream) and without losing the ability to quickly update to the latest
idris2 version (which would happen if a fork of the repo would be used).
See also: https://discourse.nixos.org/t/content-addressed-nix-call-for-testers/12881
The flake can still be used as usual, but it will gain an output `overrideOptions`, which can be used like e.g.
```nix
let
idrisx = idris.overrideOptions {
config.contentAddressedByDefault = true;
};
in { ... }
```
I suspect this function is left there accidentally after FFI was
refactored.
These functions can mislead about how FFI works.
Note these functions are private (not exported) and not used. Idris
compiler could emit a warning about such functions.
Since `[a..b]` uses `takeUntil`/`takeBefore` indirectly those too had to
be changed to `public export` clashing with `Data.Stream` definitions.
A small readability refactor was made with the `compare` function from
`EqOrd`.
Pragma once is supported by all compilers for the last ten years.
Better use it instead of include guards (which use different styles
in different files).
Support for simple signal handling was added in
a0a417240e. This commit also adds the
`_simple_handler` function. It seems to me that this function is
intended as a helper function which should only be visible in
`idris_signal.c`, it is not used outside this file. For this purpose it
is probably also marked as inline. However, the inline keyword does not
require the compiler to actually inline the function. As such, the
`_simple_handler` symbol may still be exported if the compiler doesn't
inline the function.
On my system this seems to be the case and causes the following error
during compilation of idris2:
Exception: (while loading libidris2_support.so) Error relocating Idris2-0.4.0/build/exec/idris2_app/libidris2_support.so: _simple_handler: symbol not found
By marking the `_simple_handler` function as `static inline` it is
ensured that the symbol is not exported, thereby preventing the
relocation error.
To be able to eventually refactor/extend `system` function: to be
able to specify a directory, environment variables, specify arguments
as array etc. Ideally it should be something like Rust
[`std::process::Command`](https://doc.rust-lang.org/std/process/struct.Command.html).
