Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Break
mill.bsp.worker.State
into a separate fileFold
targetTasks
intocompletableTasks
, and adjust all callsites to use thatMake
completableTasks
take atasks: BspModule => Task[W]
parameter, so we can perform all evaluation once up-front and then fall back to normal code after (rather than having it all execute in the context of the evaluator inside tasks, which obfuscates stack traces and evaluation order)Move
agg
param incompletableTasks
to a third parameter list, to allow type inference to work betterMake everything in
mill.bsp.worker
privateMove all the remaining BSP stuff from
main/
andrunner/
tobsp/
, remove weird reflection hacks to just use direct instantiation where possible since now they're in the same moduleremove the
BspServerStarter
/BspServerStarterImpl
layers of indirectionMove
BspConfigJson.scala
,bspConnectionJson
andcreateBspConnection
out ofbsp.worker
intobsp
since it doesn't depend on anything heavyweight that necessitates it being in the worker moduleMoved
def startBspServer
out ofmill.bsp.BSP
intomill.bsp.BspContext
, leavingmill.bsp.BSP
to just serve one purpose asmill.define.Module
rather than additionally being a grab-bag of helper logicSimplify the concurrency story around instantiating the
BspServerHandle
:startBspServer
was put in aFuture
, with the main result of theFuture
waiting on the server to terminate only to do some logging and discard the result, and the creation of theBspServerHandle
was propagated viaPromise
s and that the main thread wouldAwait
uponstartBspServer
, directly returning theBspServerHandle
when it completes (orLeft[String]
on error). Server termination is waited for in a side thread, that does nothing but calllistening.get()
and do logging when it terminates. We still need a global variable to pass it todef startSession
, but this can just be a@volatile var
rather than a globalPromise
Await
sOverall this PR tries to cut a lot of the unnecessary complexity and messiness around the BSP logic. This results in a substantial reduction in lines of code, while still keeping the core logic unchanged. Hopefully this will make things easier to maintain and debug going forward.
Tested manually using VSCode on
examples/misc/3-import-file-ivy