Commit Graph

48 Commits

Author SHA1 Message Date
Hubert Plociniczak
36996c8938
Don't NPE on op ._ when translating tree to IR (#8381)
Encountered a random NPE when playing with bookclubs. Test case demonstrating the problem is attached.

Threw in a bunch of minor tweaks to logs to make life of the person debugging code more pleasant.
2023-11-23 19:56:56 +00:00
Hubert Plociniczak
b8ebed69c3
Report failures when upserting visualizations (#8306)
Attaching or modifying a visualizations returns early on, to avoid a situation when a background job is stalled (by other jobs) and eventually the request timeouts.

This has an unfortunate consequence that any error reported in the `UpsertVisualizationJob` cannot be reported as a directly reply to a request because the sender has already been removed from the list.

Added more logs to discover why we get errors in the first place.

Modified the API a bit so that we carry `VisualizationContext` instead of three parameters all over the place.

Bonus:
Modified `JsonRpcServerTestKit` to implicitly require a position so that we get better error reporting on failures.
2023-11-20 11:38:51 +00:00
Jaroslav Tulach
ba19813511
Speeding up "hello world" example by 16% 2023-11-19 16:38:31 +01:00
Hubert Plociniczak
348f5170ab
Avoid NPE during instrumentation (#8317)
Fixes a random crash (*) during instrumentation. Notice how `onTailCallReturn` calls `onReturnValue` with `null` frame.

Bonus: noticed that for some reason we weren't getting logs for `ExecutionService`. This turned out to be the problem with the logger name which by default was `[enso]` not
`[enso.org.enso.interpreter.service.ExecutionService`] and there is some logic there that normalizes the name and assumed a dot after `enso`. This change fixes the logic.

(*)
```
[enso.org.enso.interpreter.service.ExecutionService] Execution of function main failed (Cannot invoke "com.oracle.truffle.api.frame.VirtualFrame.materialize()" because "frame" is null).
java.lang.NullPointerException: Cannot invoke "com.oracle.truffle.api.frame.VirtualFrame.materialize()" because "frame" is null
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onReturnValue(IdExecutionInstrument.java:246)
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onTailCallReturn(IdExecutionInstrument.java:274)
at org.enso.interpreter.instrument.IdExecutionInstrument$IdEventNodeFactory$IdExecutionEventNode.onReturnExceptional(IdExecutionInstrument.java:258)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode$EventProviderChainNode.innerOnReturnExceptional(ProbeNode.java:1395)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode$EventChainNode.onReturnExceptional(ProbeNode.java:1031)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.ProbeNode.onReturnExceptionalOrUnwind(ProbeNode.java:296)
at org.enso.interpreter.node.ExpressionNodeWrapper.executeGeneric(ExpressionNodeWrapper.java:119)
at org.enso.interpreter.node.ClosureRootNode.execute(ClosureRootNode.java:85)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.executeRootNode(OptimizedCallTarget.java:718)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.profiledPERoot(OptimizedCallTarget.java:641)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callBoundary(OptimizedCallTarget.java:574)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.doInvoke(OptimizedCallTarget.java:558)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedCallTarget.callDirect(OptimizedCallTarget.java:504)
at jdk.internal.vm.compiler/org.graalvm.compiler.truffle.runtime.OptimizedDirectCallNode.call(OptimizedDirectCallNode.java:69)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNode.doCached(ThunkExecutorNode.java:69)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNodeGen.executeAndSpecialize(ThunkExecutorNodeGen.java:207)
at org.enso.interpreter.node.callable.thunk.ThunkExecutorNodeGen.executeThunk(ThunkExecutorNodeGen.java:167)
...
```

# Important Notes
Fixes regressions introduced in #8148 and #8162
2023-11-17 14:38:27 +00:00
Dmitry Bushev
565a858c5f
Inline Execution (#8148)
close #8132

Update the `executionContext/executeExpression` request to execute expressions in the local scope.
2023-11-13 16:05:05 +00:00
Hubert Plociniczak
f21e09bb65
More logs to debug failed edits (#8251) 2023-11-08 15:06:17 +00:00
Hubert Plociniczak
21dc90a0ed
OpenFileCmd sends a reply when finished (#8225)
* OpenFileCmd sends a reply when finished

Lack of reply and therefore a non-determinism on when OpenFile handler
can finish, led to some sporadic instability. Once caches format got
changed, things were taking such a long time that I wasn't able to start
even a basic project (requests would start to timeout).
The change also removes PushContextCmd from synchronous cmds (as
introduced in #798 to remove initialization problems in tests as well as
in real scenarions); the change did the job but was also a bit
controversial.
The change can also help with randomly failing applies (#8174) as IDE kept
closing and opening the project that might have exploited the
race-condition.

* Adapt tests

* Make tests more resilient to out of order messages

* Drop retries that lead to confusing errors

* less random failures

* s/OpenFileNotification/OpenFileRequest
2023-11-07 23:59:42 +01:00
Jaroslav Tulach
3fd2249864
Introducing engine/runtime-compiler project (#8197) 2023-11-01 12:42:34 +01:00
Jaroslav Tulach
f2cfd7f86c
Allow reassigning of BindingsMap (#8190)
Fixes #8186 by turning `IllegalStateException` into log message. Re-assigning of `BindingsMap` can happen in the IDE where evaluation of modules is repeated again and again. In addition to that avoid dropping errors in compiler without them being noticed.
2023-10-31 10:03:37 +00:00
Jaroslav Tulach
646b47b246
Caches belong to runtime, not IR compiler (#8178) 2023-10-30 16:53:44 +01:00
Hubert Plociniczak
10f35390a1
Translate IR to Java (#8145)
Towards reduced reliance on Scala semantics.
Translated IR.scala to IR.java and extracted implicits that now need to be imported explicitly.

# Important Notes
1:1 translation. For now `@Identifier` and `@ExternalID` represent the old type aliases but are not verified at compile time.
This is because in a mixed Scala/Java world this seems impossible to employ such frameworks as Checker.
2023-10-26 07:31:08 +00:00
Jaroslav Tulach
5e468f08ad
Introducing CompilerContext.Module (#8144) 2023-10-25 17:11:47 +02:00
Dmitry Bushev
b1df8b1889
Initialize suggestions database only once (#8116)
close #8033

Changelog:
- update: run language server initialization once
- fix: issues with async `getSuggestionDatabase` message handling in new IDE
- update: implement unique background jobs
- refactor: initialization logic to Java
- refactor: `UniqueJob` to a marker interface
2023-10-21 20:32:13 +00:00
Hubert Plociniczak
aa88dfeb2f
More debug info for failed edits (#8107)
Unmasked position info for the failed edits so that it is possible to understand what edits are attempted at all. So far unable to locate the problem based solely on the logs and the stacktrace. Added a test confirming that making edits at the end of the file continues to be fine (that's where the problem usually manifests itself).

# Important Notes
References #7978
2023-10-19 13:46:42 +00:00
Hubert Plociniczak
ab2da9e436
Ambiguous imports warnings/errors are serializable (#8093)
`AmbgiuousImport` error and `DuplicatedImport` warning must not have `Source` as one of its fields or compiler will crash during a serialization attempt.
Changed the implementation to provide it as a parameter to the `message` method instead.

Fixes #8089
2023-10-18 21:51:58 +00:00
Dmitry Bushev
58eeba6a00
Suppress futile visualization warnings (#8056)
close #7819

Warnings
```
Execution of visualization [...] on value [...] of [Panic] failed.
```
are produced when you are typing an incomplete expression in the component browser and can be misleading.
2023-10-16 08:23:43 +00:00
Hubert Plociniczak
a96f2d7aba
Fix initialization race-condition in runtime connector (#7985)
It seems that Runtime Connector wasn't respecting the protocol it defined itself. The connector should be waiting on the `Api.InitializedNotification` message and only then start forwarding messages. So far it seems this hasn't been a problem, or at least wasn't reported as such, because initialization was fast enough.

Modified `Handler` so that we are certain that its fields hold initialized values when being accessed by different threads.

Should fix problems mentioned in #7898.
2023-10-13 10:03:27 +00:00
Jaroslav Tulach
b5d50e6d63
Avoid Null receiver values are not supported by libraries (#8044) 2023-10-13 11:41:43 +02:00
Jaroslav Tulach
ef76df4c38
Define and enforce locking order during runtime (#8014) 2023-10-11 13:49:58 +02:00
Jaroslav Tulach
a234e82ee9
Instrumenter to observe behavior of nodes with UUID (#7833)
Exposing instrumentation capabilities to Enso. Fixes #7683.
2023-10-10 02:36:59 +00:00
Hubert Plociniczak
16c8d2e302
Remove context locks from visualization commands (#7953)
It looks like visualization commands had required context lock unnecessairly. Context manager methods are synchronized and therefore should not need the lock before submitting a correspodning background job.

Additionally, the presence of a context lock leads a deadlock:
1. Consider a long running execution of a program that does not finish within the 5 seconds
2. In the meantime there comes either an `AttachVisualization` or `DetachVisualization` request from the client

The latter will get stuck and eventually timeout out because it cannot acquire the lock withing the required time limits. It is still possible that a single long-running `ExecuteJob` might block other ones (including visualization ones) but that's a separate work.

Fixes some issues present in #7941.

# Important Notes
We need to still investigate `ExecuteJob`s need for context lock which might delay the execution of other background jobs that require it as well (mostly concerned about visualization).
2023-10-06 16:48:38 +00:00
Dmitry Bushev
f1356374e1
Restore execution environment before the execution complete notification (#7980)
Fixes flaky RuntimeServerTest https://github.com/enso-org/enso/actions/runs/6410804439/job/17420283503?pr=7953#step:10:4004
2023-10-05 14:25:17 +00:00
Jaroslav Tulach
aada58e549
Removal of unused onExceptionalCallback (#7970) 2023-10-04 16:15:29 +02:00
Jaroslav Tulach
0efa1afc61
Encapsulate TruffleLanguage.Env in EnsoContext (#7842) 2023-09-20 11:30:44 +02:00
Jaroslav Tulach
4caee1b00f
Cleanup code in IdExecutionInstrument (#7811)
As part of investigation of #7683, let's make `IdExecutionEventNode` smaller by having a reference to factory and its fields.
2023-09-15 10:09:42 +00:00
Dmitry Bushev
e5425d35a0
Log visualization expressions generated by IDE (#7756)
close #7608

Changelog:
- update: log separately the evaluation of visualization expression and its arguments
- update: add visualization expression, its arguments, and the value type to the log

# Important Notes
Example

```
[TRACE] [2023-09-06T20:41:45+03:00] [enso] Executing visualization [VisualizationConfiguration(d195fdd8-d4e8-400f-a0d4-e50417eddd0a,ModuleMethod(MethodPointer(Standard.Visualization.Table.Visualization,Standard.Visualization.Table.Visualization,prepare_visualization),Vector(1000)),local.New_Project_1.Main)] on expression [ddc060df-9b59-48e5-bc61-aca849347343] of [class org.enso.interpreter.runtime.data.vector.Vector$Generic]...
```
2023-09-12 17:27:37 +00:00
Hubert Plociniczak
24f263b20b
Towards shallow nesting in IR (#7681)
Refactoring deeply nested IR classes to shallow nesting.
Fixes #7017

# Important Notes
It's a big PR but fairly consistent. Split multiple hierarchy levels into subpackages.
2023-08-31 15:42:53 +00:00
Dmitry Bushev
eefe74ed93
When opening the project for a second time suggestion database is not sent (#7699)
close #7413

Changelog:
- update: the language server listens for the client disconnection event and invalidates the suggestions index

# Important Notes
The component browser contains suggestion entries after the refresh


https://github.com/enso-org/enso/assets/357683/bcebb8bf-e09f-4fb0-86cf-95ced58413f3
2023-08-31 14:06:58 +00:00
Dmitry Bushev
5dc2c4c5fd
Notification about the project rename action (#7613)
close #7604

After moving the rename action to the dashboard, IDE is unaware of the new project name. PR implements a new `refactoring/projectRenamed` notification that is sent from the server to clients and informs them about the changed project name.

# Important Notes
https://github.com/enso-org/enso/assets/357683/7c62726d-217e-4e69-8e48-568e0b7b8c34
2023-08-22 11:32:46 +00:00
Dmitry Bushev
1d67667792
Editing the node is not changing the placeholders and widgets (#7595)
close #7462

# Important Notes
https://github.com/enso-org/enso/assets/357683/c2e68042-f64c-419e-b36e-7e99f0b43cd8
2023-08-18 14:22:26 +00:00
Dmitry Bushev
b7ab6911ff
Renaming Variable or Function Support (#7515)
close #7389



Changelog:
- add: `refactoring/renameSymbol` request to rename locals or module methods
2023-08-10 21:16:33 +00:00
Hubert Plociniczak
162debb88c
Avoid NPEs during regular execution (#7482)
Seeing plenty of
```
java.lang.NullPointerException: Some(Null receiver values are not supported by libraries.)
at org.graalvm.truffle/com.oracle.truffle.api.library.LibraryFactory.dispatch(LibraryFactory.java:528)
at org.graalvm.truffle/com.oracle.truffle.api.library.LibraryFactory.getUncached(LibraryFactory.java:396)
at org.enso.interpreter.runtime.error.WarningsLibraryGen$UncachedDispatch.hasWarnings(WarningsLibraryGen.java:440)
at org.enso.interpreter.instrument.job.ProgramExecutionSupport$.sendExpressionUpdate(ProgramExecutionSupport.scala:366)
at org.enso.interpreter.instrument.job.ProgramExecutionSupport$.$anonfun$executeProgram$1(ProgramExecutionSupport.scala:62)
at org.enso.interpreter.instrument.job.ProgramExecutionSupport$.$anonfun$executeProgram$10(ProgramExecutionSupport.scala:151)
at java.base/java.lang.Iterable.forEach(Iterable.java:75)
at org.enso.interpreter.instrument.job.ProgramExecutionSupport$.executeProgram(ProgramExecutionSupport.scala:139)
at org.enso.interpreter.instrument.job.ProgramExecutionSupport$.$anonfun$runProgram$3(ProgramExecutionSupport.scala:217)
```
during execution of simple programs.
Added a guard to prevent us from sending expression updates when dealing with nulls.
2023-08-07 08:25:27 +00:00
Dmitry Bushev
509f8a5eac
Runtime instrumentation is being used before finishing instrumentation (#7370)
close #7206

fixes

```
[error] [2023-07-04T08:43:55.015Z] [akka.actor.OneForOneStrategy] Cannot invoke "org.enso.interpreter.instrument.execution.CommandProcessor.stop()" because the return value of "org.enso.interpreter.instrument.Handler.commandProcessor()" is null
java.lang.NullPointerException: Some(Cannot invoke "org.enso.interpreter.instrument.execution.CommandProcessor.stop()" because the return value of "org.enso.interpreter.instrument.Handler.commandProcessor()" is null)
at org.enso.interpreter.instrument.Handler.onMessage(Handler.scala:119)
at org.enso.interpreter.instrument.Endpoint.$anonfun$sendBinary$1(Handler.scala:66)
at org.enso.interpreter.instrument.Endpoint.$anonfun$sendBinary$1$adapted(Handler.scala:64)
at scala.Option.foreach(Option.scala:437)
at org.enso.interpreter.instrument.Endpoint.sendBinary(Handler.scala:64)
at org.graalvm.truffle/com.oracle.truffle.api.instrumentation.TruffleInstrument$Env$MessageTransportProxy$MessageEndpointProxy.sendBinary(TruffleInstrument.java:1052)
at org.enso.languageserver.runtime.RuntimeConnector$$anonfun$initialized$1.applyOrElse(RuntimeConnector.scala:79)
at scala.runtime.AbstractPartialFunction.apply(AbstractPartialFunction.scala:35)
at org.enso.logger.akka.ActorLoggingReceive.apply(ActorLoggingReceive.scala:35)
at org.enso.logger.akka.ActorLoggingReceive.apply(ActorLoggingReceive.scala:14)
at scala.PartialFunction.applyOrElse(PartialFunction.scala:214)
at scala.PartialFunction.applyOrElse$(PartialFunction.scala:213)
at org.enso.logger.akka.ActorLoggingReceive.applyOrElse(ActorLoggingReceive.scala:14)
at scala.PartialFunction$Combined.applyOrElse(PartialFunction.scala:305)
at akka.actor.Actor.aroundReceive(Actor.scala:537)
at akka.actor.Actor.aroundReceive$(Actor.scala:535)
at org.enso.languageserver.runtime.RuntimeConnector.aroundReceive(RuntimeConnector.scala:20)
at akka.actor.ActorCell.receiveMessage(ActorCell.scala:579)
at akka.actor.ActorCell.invoke(ActorCell.scala:547)
at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:270)
at akka.dispatch.Mailbox.run(Mailbox.scala:231)
at akka.dispatch.Mailbox.exec(Mailbox.scala:243)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
```
2023-07-23 11:40:38 +00:00
Jaroslav Tulach
6864792653
Avoid Compiler compile time dependency on EnsoContext (#7299) 2023-07-17 09:24:22 +01:00
Hubert Plociniczak
a140a04689
A dataflow error with warnings reports the former (#7205)
A dataflow error resulting from calling a value with warnings now
reports only the error rather than the warning.

Closes #7141.
2023-07-05 14:18:36 +02:00
Hubert Plociniczak
3c93c25a5a
Reload project's config on rename (#7179)
Package's config information, once loaded, never changed. While there is typically no need for it, this was problematic when the config became out-of-sync with the filesystem, like in the case of project rename action.
In rename, the config's properties would be updated in the FS, but that would never be reflected in module's package. Therefore further compilations would continue to ask for the old namespace.

Most of the changes are cosmetic (s/`.config`/`.getConfig()`) except for the new `reloadConfig` method on `Package` that is being called in `RenameProjectCmd` handler.

Closes #7062.

# Important Notes
The reported `ExecutionFailed` error should have been mostly fixed already via #7143. This change makes sure that all the related warnings are gone as well and the compiler uses the updated namespace.
2023-07-03 09:36:19 +00:00
Dmitry Bushev
66894bd79e
Send info about function values (#7168)
close #6957

Extend `ExpressionUpdate` message and send a function schema if the returned value is a function.
2023-06-30 13:31:48 +00:00
Hubert Plociniczak
bf5ddf3de0
Send executionComplete response only on success (#7143)
`executionFailed` instead is sent when an evaulation finishes with a a critical failure or a non-critical error.
The PR tries to miniminally modify the change in the messages exchange so as to avoid a major redesign at this point.

Closes #7002.

# Important Notes
Unblocks IDE which will need to modify to this new setup.
2023-06-29 07:35:28 +00:00
Jaroslav Tulach
477dd82670
Drop-down widgets for extension functions via UnresolvedSymbol (#7115)
Fixes #6955 by:
- using `visualisationModule` to specify the module where the visualization is to be used
- referring to method in `Meta.get_annotation` with `.method_name` - e.g. unresolved symbol notation
- evaluating arguments to `Meta.get_annotation` in the context of the user module (which can access the extension functions)
2023-06-27 15:19:42 +00:00
Dmitry Bushev
22259e696d
Add method call info for infix operators (#7090)
close #6374

In order to provide the method pointer information, the `IrToTruffle` pass sets the module name and the type name of the builtin node.
2023-06-27 13:11:12 +00:00
Hubert Plociniczak
4e5cb9cca6
Consistent naming of visualization (#7124) 2023-06-26 17:04:35 +00:00
Jaroslav Tulach
6abcbcb00c
Moving construction of IR into runtime parser project (#7096) 2023-06-24 06:34:21 +02:00
James Dunkerley
90df5adfb0
Fix defect where constructor fields not show for Value constructors. (#7080)
The `IdExecutionService` now uses `getName` not `getDisplayName` for atomConstructor.
`getDisplayName` adjusts the name if the name is `Value` or `Error`, which meant no parameters in IDE.

Before:
![image](https://github.com/enso-org/enso/assets/4699705/ddc564fe-3213-46ec-9684-ab718f8bb0bb)

Now:
![image](https://github.com/enso-org/enso/assets/4699705/59d3ece4-1148-44bb-8a13-7bc3db8dfca2)
2023-06-20 12:47:16 +00:00
Hubert Plociniczak
e529f7bb3b
Improvements that significantly reduce the chances of request timeouts (#7042)
Request Timeouts started plaguing IDE due to numerous `executionContext/***Visualization` requests. While caused by a bug they revealed a bigger problem in the Language Server when serving large amounts of requests:
1) Long and short lived jobs are fighting for various locks. Lock contention leads to some jobs waiting for a longer than desired leading to unexpected request timeouts. Increasing timeout value is just delaying the problem.
2) Requests coming from IDE are served almost instantly and handled by various commands. Commands can issue further jobs that serve request. We apparently have and always had a single-thread thread pool for serving such jobs, leading to immediate thread starvation.

Both reasons increase the chances of Request Timeouts when dealing with a large number of requests. For 2) I noticed that while we used to set the `enso-runtime-server.jobParallelism` option descriptor key to some machine-dependent value (most likely > 1), the value set would **only** be available for instrumentation. `JobExecutionEngine` where it is actually used would always get the default, i.e. a single-threaded ThreadPool. This means that this option descriptor was simply misused since its introduction. Moved that option to runtime options so that it can be set and retrieved during normal operation.

Adding parallelism intensified problem 1), because now we could execute multiple jobs and they would compete for resources. It also revealed a scenario for a yet another deadlock scenario, due to invalid order of lock acquisition. See `ExecuteJob` vs `UpsertVisualisationJob` order for details.

Still, a number of requests would continue to randomly timeout due to lock contention. It became apparent that
`Attach/Modify/Detach-VisualisationCmd` should not wait until a triggered `UpsertVisualisationJob` sends a response to the client; long and short lived jobs will always compete for resources and we cannot guarantee that they will not timeout that way. That is why the response is sent immediately from the command handler and not from the job executed after it.

This brings another problematic scenario:
1. `AttachVisualisationCmd` is executed, response sent to the client, `UpsertVisualisationJob` scheduled.
2. In the meantime `ModifyVisualisationCmd` comes and fails; command cannot find the visualization that will only be added by `UpsertVisualisationJob`, which might have not yet been scheduled to run.

Remedied that by checking visualisation-related jobs that are still in progress. It also allowed for cancelling jobs which results wouldn't be used anyway (`ModifyVisualisationCmd` sends its own `UpsertVisualisationJob`). This is not a theoretical scenario, it happened frequently on IDE startup.

This change does not fully solve the rather problematic setup of numerous locks, which are requested by short and long lived jobs. A better design should still be investigated. But it significantly reduces the chances of Request Timeouts which IDE had to deal with.

With this change I haven't been able to experience Request Timeouts for relatively modest projects anymore.

I added the possibility of logging wait times for locks to better investigate further problems.

Closes #7005
2023-06-16 17:57:16 +00:00
Pavel Marek
67821bf8df
Add compiler pass that discovers ambiguous imports (#6868)
Add a new compiler pass that analyses duplicated and ambiguous symbols from imports
2023-06-14 12:18:57 +02:00
Dmitry Bushev
6249c79ffd
Update sbt-java-formatter plugin (#7011)
Update java formatter plugin. The new version can remove unused imports.
2023-06-12 14:18:48 +00:00
Hubert Plociniczak
5c3d6a7d6f
Eliminate race condition for edit/close/open cmds (#6998)
There was an inherent race condition between edit, close & open commands which could not be prevented solely using locks. `EditFileCmd` triggered `EnsureCompiledJob` which was applying edits collected over time. At the same `CloseFileCmd` and `OpenFileCmd` were executed asynchronously and required locks on compilation unit  and file lock.

Additionally, open file was resetting the module's runtime source irrespective of any edits that could already have been applied with the asynchronous execution in `EnsureCompiledJob`. This was visible especially during early manipulation of the project when open/close was performed due to a bug in IDE (#6843).

Now commands can be run either synchronously or asynchronously. Only that way can we ensure that `close` & `open` commands finish by the time any editions are being applied to module's sources.

Closes #6841.

# Important Notes
In the given video, `"foo"` would be greyed out because it would never be part of the module's (runtime) sources. Therefore no IR would be generated for it or instrumentation, meaning it would be present in `expressionUpdates` information necessary for IDE.

[Kazam_screencast_00014.webm](https://github.com/enso-org/enso/assets/292128/226a17b8-729a-415a-803f-003a9695b2f1)
2023-06-09 12:12:46 +00:00
Jaroslav Tulach
e6652b8c9f
Separating instrument related files into runtime-instrument-common project (#6992) 2023-06-08 16:51:50 +02:00