;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Current Lwt_platform ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; history: Lwt_platform used to be important when we distributed Semgrep via
;; the `js_of_ocaml` (jsoo) compiler, and the regular Semgrep binary.
;; In the jsoo world, many Unix-specific things are not possible, and so we had
;; to provide a lot of alternate implementations of functionality that the
;; Semgrep binary needed.
;; In particular, when running the Lwt-based language server, we needed to play
;; nice with JS's single-threaded event loop. `Lwt_main.run` and friends are not
;; available in the jsoo world, so we used virtual modules to swap out Unix-and
;; -JS-specific implementations of Lwt primitives.
;; Now that we have killed the jsoo distribution, we no longer need two
;; implementations, but Lwt isn't long for this world anyways (hopefully), so let's
;; still just keep around the single virtual module.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
; Old Lwt_platform ;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; What is this? And why are we doing it?
;; Lwt uses unix threads to run its stuff on, which means it doesn't work in Js_of_ocaml
;; This library uses Dune's virtual modules. The way this works is that code can use
;; this library's interface, lwt_platform, and get type checking and everything without
;; having to choose a specific implementation. Then, when we link, we can choose
;; which implementation to use.
;;
;; Why do we need this in general? There's a lot of [Lwt_main.run] calls in osemgrep
;; in order to run async code. As mentioned, this uses unix threads, and so the underlying
;; library, lwt.unix, pulls in unix dependencies. This means that we can't use lwt.unix
;; in any code shared by osemgrep and LSP.js/turbo mode, etc., or else we'll get
;; unix dependencies in the browser that won't work. So we can't make this a functor,
;; as the shared networking code would have to be functorized over the Lwt implementation.
;; Which means we'd have to pull in the lwt.unix dependency in the shared code, or use functors
;; in like 5 or 6 different modules which would be a pain. We also can't use a ref for a similar reason,
;; we'd have to pull in the lwt.unix dependency in the shared code, or have a ton of refs everywhere.
;; Also, top level refs cannot be polymorphic, so we'd have to use a module ref or something similar
;;
;; This makes it so the DevEx is relatively painless, and we can just use the same code.

(library
 (public_name lwt_platform)
 (wrapped false)
  (libraries
    lwt
    commons
  )
 (virtual_modules lwt_platform)
)
