Commit Graph
12 Commits
Author SHA1 Message Date
Emilie Burgun e68ac8347f Document run_module_predicate and handle critical failure in toplevel.pl 2025-02-06 13:36:23 +01:00
Emilie Burgun d4bf52e82c Disable test_run_module_predicate_throw under miri and support rustc < 1.83 2025-02-06 10:37:54 +01:00
Emilie Burgun 22538a05be Fix backtracking on the topmost predicate triggering UB in run_module_predicate
Fixes #2815, see that issue for my investigation.

This is a one-line fix that I'm quite proud of :)

If the topmost query for `run_module_predicate` needs to backtrack,
then before this commit, one of the following two things may happen:
- A dangling OrFrame is read at stack offset 0
- An AndFrame was at stack offset 0 would be read as an OrFrame

This can be seen by either calling `run_module_predicate` with a
throwing predicate (encountering the second scenario) or a failing
predicate (encountering the first scenario), or by running the following
in the REPL, which triggers a `throw/1` within the error handler, propagating
it all the way up (and encountering the second scenario):

```prolog
?- current_output(S), open(stream(S), write, S0, [type(binary)]).
```

Currently, `Stack` is not equipped with tools to detect this incorrect
behavior, so it would instead try to read an OrFrame at offset 0, which
triggers UB, since transmuting between AndFramePrelude and OrFramePrelude
isn't legal.

In practice, since `AndFramePrelude` is smaller, the later fields of
`OrFramePrelude` would read from the cells following the `AndFramePrelude`,
and would contain nonsensical data, triggering the panic that led to
my investigation in #2815 and that is fairly reliable to witness.

Surprisingly, this wouldn't happen with `run_query`, which led me to
look at how they operate differently. It turns out that `run_query`
inserts an OrFrame at offset 0, which covers both problematic scenarios.

The fix is thus to simply add a call to `Machine::allocate_stub_choice_point`
in `run_module_predicate` :)
2025-02-06 00:43:01 +01:00
Emilie Burgun 0cde8f9a43 Add integration tests for arithmetic operators
This extensively tests the behavior of is/2, both when compiled and in metacalls.
2025-01-27 00:10:56 +01:00
Emilie Burgun 20735ea34c Fix integer overflow in >>/2 and <</2 2025-01-27 00:10:47 +01:00
Emilie Burgun f3a92c6551 Fix min/2 and max/2 returning the cast version of its arguments
It now behaves the same way as SWI-Prolog.
2025-01-27 00:06:06 +01:00
Emilie Burgun e2d1a2b6bc Fix X is gcd(1, 2 ^ 64) triggering a panic
The implementation for gcd/2 would cast the second argument to an isize.
2025-01-27 00:06:06 +01:00
Emilie Burgun d3361c16d8 Fix round() losing precision on bigints
The original issue can be reproduced with `X is round(2 ^ 54 + 1) - 2 ^ 54, X = 1.`
2025-01-27 00:05:30 +01:00
Emilie Burgun 9420c7e41e Fix rnd_i clipping floats that don't fit in Fixnum
Fixes #2772.

The current implementation of `rnd_i` incorrectly casts `f` (an `f64`)
into an `i64`, before casting it into an `Integer`.

This fixes that issue by using `Integer::try_from(f)` instead,
and failing if `f` is infinite or NaN.

A fixme is left for a future PR to properly handle the resulting errors
in floor/1 and friends (right now they can only be triggered through FFI).
2025-01-27 00:02:04 +01:00
Emilie Burgun b76bdd75e4 Fix #2725 by calling load_context/1 in the unspecified branch of strip_module/3
This fixes #2725, by making it so that `strip_module(Pred, M, P), call(M:P)`
doesn't throw an `instanciation_error` when `Pred` isn't in the form `module:predicate`.

Now, `strip_module(hello, M, P)` will call `load_context(M)`, which unifies `M`
with the topmost module (or `user`).

Two new test cases are added: issue2725.pl, which tests the minimal case id(X) --> X.
and the strip_module(P, M, _), call(M:P) scenario, and module_resolution,
which tests the behavior of strip_module in a few scenarios.
2025-01-12 14:08:28 +01:00
Emilie Burgun eff094cc29 Add tests for PR #2756 2025-01-08 17:57:40 +01:00
Emilie Burgun 6cedbc33c0 Fix load_context_module triggering unreachable code in unify_atom 2025-01-08 17:57:40 +01:00