nfnl client errors when evaluating a macro that contains a function

[jship]

When evaluating some Fennel code that uses a macro and that macro has a local function defined, Conjure errors with:

; --------------------------------------------------------------------------------
; eval (buf): <path-omitted>/src/app.fnl
; [Compile] .../.config/nvim/bundle/conjure/lua/conjure/nfnl/fennel.lua:1069: attempt to index field 'options' (a nil value)

That erroring line in fennel.lua has me suspect Conjure's initialization of fennel is mixed up if fennel's options haven't been defined yet, maybe through Conjure's (or nfnl's) use of autoload?

Here is a small repro - note this also depends on nfnl.module:

❯ tree -a
.
├── .nfnl.fnl
└── src
    ├── app.fnl
    ├── app.lua
    └── macros.fnlm

2 directories, 4 files

❯ cat .nfnl.fnl
{:source-file-patterns ["src/*.fnl"]}

❯ cat src/macros.fnlm
(fn foo []
  ;; Evaluating src/app.fnl in Conjure will succeed if this next line is removed
  (fn dummy [] nil)
  true)

{: foo}

❯ cat src/app.fnl
(import-macros m :src.macros)

(local {: define} (require :nfnl.module))

(local M (define :src.app))

(fn M.test []
  (m.foo))

M

If I comment out the dummy fn above, restart nvim, and try evaluating src/app.fnl, it works fine. At that point, I can then uncomment dummy, evaluate src/app.fnl and evaluation continues to succeed, but the updates to the macro do not seem to propagate. For example, if I change src/macros.fnlm to the following:

(fn foo []
  (fn dummy [] nil)
  (dummy))

{: foo}

Then re-evaluate src/app.fnl, evaluating (M.test) still returns true from the original version of src/macros.fnlm, rather than nil.

As this repro also uses nfnl, it's worth pointing out that nfnl compilation never errors, and the generated src/app.lua is always up-to-date with the actual macro contents whenever src/macros.fnlm is saved.

[jship]

I checked the above over using the stdio Fennel client and it worked great. On this bit specifically:

...but the updates to the macro do not seem to propagate.

Macro changes propagate if the macro module is reloaded via <localleader>eF in the stdio client. Since the nfnl client doesn't have an equivalent of the stdio client's reload command as far as I'm aware, I take it the lack of propagation is expected in the nfnl client. Wanted to make that distinction to avoid confusion. The core of the above issue is still as described, in that the nfnl client errors during the evaluation of code using a macro, when that macro has a local function.