I have now fixed this locally using the new diagnostic infrastructure.

Best, Kento

On Thu Nov 21, 2024 at 2:16 PM CET, Jon Sterling wrote:
>
> On Thu, Nov 21, 2024, at 12:30 PM, Nick Hu wrote:
> > (Apologies if you get multiple copies of this bug report, I tried
> > sending it directly to ~jonsterling/forester@todo.sr.ht but for whatever
> > reason that didn't work.)
>
>
> Hi Nick,
>

Hi Nick, thanks for the report.

I recently made some major changes to the way diagnostics are handled
internally. I have not yet pushed those changes, but the gist of it is
that diagnostics will be accumulated for each compilation phase so that
we can decide which errors to display towards the end of the compilation
run. It turns out that the error you reported does not occur for me when
using the new infrastructure, but is not reported at all (incidentally,
it is reported in the lsp). I will track this down and fix it.

Best, Kento

> (Apologies if you get multiple copies of this bug report, I tried
> sending it directly to ~jonsterling/forester@todo.sr.ht but for whatever

On Mon Nov 18, 2024 at 6:46 PM CET, Kento Okura wrote:
> This includes some changes to code outside of the lsp module:

I forgot to mention: I will apply this myself on the lsp-refactor
branch, I sent it for code review

> - The "--dest" option is removed. Instead, forester will use the
>   directory that contains the latest tree of the specified prefix.
>   In random mode, it will put the tree in some directory that also
>   contains a tree of the prefix.
>
>   The reason for this change is that there is no way to specify a
>   destination directory from using the code action interface (at least I
>   don't know how this would be done)

This includes some changes to code outside of the lsp module:

- The "--dest" option is removed. Instead, forester will use the
  directory that contains the latest tree of the specified prefix.
  In random mode, it will put the tree in some directory that also
  contains a tree of the prefix.

  The reason for this change is that there is no way to specify a
  destination directory from using the code action interface (at least I
  don't know how this would be done)

- The config parser now parses a key "prefixes". This is necessary to
  create the code actions.
---
[message trimmed]

Thanks! I have now applied your patch on the 5.0 branch.

Best, Kento

On Tue Nov 12, 2024 at 1:15 PM CET, Nick Hu wrote:
> This will make it so that the cachix config can be automatically
> installed (the user is promped on first access).
>
> (Compiling is very slow on my laptop...)
>
> ---
>  flake.nix | 4 ++++
>  1 file changed, 4 insertions(+)
>

My bad, I was not using my development version of forester when testing,
this should be fixed now. Owen, can you confirm tihs issue no longer
occurs on the latest commit?

Best, Kento

I reverted that commit, but that did not fix the issue... Will keep at
it.

I think it has to do with the use of fibers in `Map_reduce.ml`: I
suspect that what is happening inside here is opaque to the outer
reporter:

```
module Make (I: Input) = struct
  let reduce ?(max_fibers = 20) ?(init = I.nil) ~env inputs =
    List.fold_left I.plus init @@
      Eio.Fiber.List.map ~max_fibers (I.eval env) inputs
end
```

Hi all,

so my suspicion was wrong, and I need to investigate this more, but I
*can* reproduce it.'

> For the issue raised by OP, it's indeed better to recognize the
> deprecated syntax and prompt accordingly, instead of dropping the user
> to a mysterious internal error.

Of course, this behavior is unintended, but it seems that this does not
have to do with the removal of transclusion overrides, as I see the same
error on something like this:

```

To clarify, it seems that you are aware of the deprecation, but I think
that there is some erroneous logic in the error reporting that does not
abort the computation, hence the confusing stack trace.