Being able to analyse OCaml code like this seems pretty cool, even if this particular use didn’t find anything. Maybe it would help with Why Ocsigen is staying on Lwt (for now) for example?
I don’t think I have. I have had the opposite problem though: when running Eio and Lwt code together, I’d like to be sure that the Lwt code doesn’t perform an Eio effect, even though it will be handled. This can result in deadlock because Lwt assumes that all code returns immediately (if the code needs to wait, it will immediately return a promise).
Lwt_eio has Lwt_eio.with_event_loop ~debug:true, which catches all effects from Lwt code and reports an error, but a static analysis might be better.
The main case I worry about is callbacks from C to OCaml, since effects don’t work over a C call (C functions can’t be suspended).
The most common case of unhandled effects in Eio is in unit-tests, since you don’t need to start an event loop to get access to mock resources for testing, so it’s easy to forget. But a runtime error is reported immediately, so there’s no benefit to static analysis here.