After calling `grow()`, the new head would jump to `old_capacity` rather
than staying to the same offset.
In practice this only loses a few bytes at most.
This is the first step towards enabling multithreading on AtomTable.
For now RawBlock will default to using Cell, which yields a byte-
equivalent compiled output.
Also adds an `atomic` feature, which, when enabled, will make RawBlock
use an AtomicPtr instead, ensuring that it implements `Sync`.
This one was a toughie: it turns out that using `ptr::align_of()`` was
a bad idea, since the buffer in `Heap` itself is not aligned to
`Heap::heap_cell_alignment()`, so `ptr::align_of()` would sometimes
return lower values than expected.
That made for an heisenbug: if the alignment of the heap happened to be 4,
then the bug wouldn't trigger.
Before this change, the following set of queries would behave incorrectly:
```
?- open("/tmp/out.log", write, S), set_output(S).
prints(""), write("/tmp/out.log", "S = stream(...)").
?- write(user_output, hello).
prints("hello"), unexpected.
prints(""), write("/tmp/out.log", "hello"). % Expected, but not found.
```
Now, `set_output/1` and `set_input/1` properly bind the `user_output` and
`user_input` aliases, making the queries above behave as expected.
These two fields are able to hold `Stream` instances, which predicates like `close/1`
expect to be managed properly for their correctness. To ensure that this is the case,
I have removed direct accesses to those two fields, so that they can be properly managed
in one place.
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` :)
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).
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.
Emilie Burgun