"org.typelevel" %% "cats-effect" % "2.1."to no avail :(
@niktrop I'm currently reimplementing scala-async as a phase of the compiler: scala/scala#8816 . A few details of name mangling are changing and I'm investigating how to adapt intellij-scala to these.
The refactoring effort is in part to support a user of scala-async that integrates it via a compiler plugin that demarcates async blocks with annotations. The effect is quite similar to Kotlin's suspend functions. So I'd also like to find a way to make support for async in "evaluate expression" work in their environment, too. My idea is to detect replace (or augment) the current
InsideAsync static analysis with a dynamic analysis of the enclosing classes in the VM at the breakpoint. If one of these has the 'fingerprint" of an async state machine, we can trigger the strategy of evaluating local variables and methods as selections of fields and methods from the state machine class.
Does this sound like a reasonable approach? How does Kotlin's compiler/debugger handle things?
While looking at this, I noticed at least one bug and an inefficient implemetation in some code contributed (as part of JetBrains/intellij-scala#386) to the the debugger. I'm tring to rework this in: https://github.com/retronym/intellij-scala/pull/1/commits/ea56504671599f5f837c21a05f592a154b141d4f
For both of these changes I'd like to add a test case. I have a manual test in https://github.com/retronym/boxer/blob/topic/xasync/README.md. But rather than trying to introduce another third-party dependency to your build, I was thinking it would be simpler to have a debugger test that has one set of sources that will be loaded in the project when debugging, and a "shadow" set of sources that will be used to create the classfiles. The "shadow" sources can include the expansions that a compiler plugin would have made. If you think this approach makes sense,