Feature: Better KCL error reporting and display of errors in the UI

[nadr0]

relates #5192

Issue

• LSP diagnostics do not get piped to the UI. They are clobbered because we compute this upon execution
• LSP, safeParse, execution are all tied to "execution"
• Multiple parts of the system can produces valid errors but do not run in parallel because of the execution loop
• Selecting a file is tied to execution
• Compilation errors are stored different than execution/run time errors

Future

• A user should be able to see how many errors are in their current file
• A user should be able to see how many project wide errors there are
• LSP should run on all files in the project upon open or if a file externally changes
• We should be able to handle LSP errors anytime we want, not specifically on execution

Reporting errors to the user

• Code pane should report how many errors are in the current file
• Project pane should report total project errors (LSP + any last runtime issues)
• We could add a third location which is a status bar that summarizes all of the errors
  • When expanded it could show the list of all the locations and you can click each one to go to that error.

Gotchas

• Would we be spamming LSP on all files within the project whenever the project loads or a file contents change?
• Do we want to show a difference between compilation/parse errors vs runtime errors?

DOM

• Code pane shows 1 error
• File shows 1 error
• Project says 5 errors
• File tree says 1 file error + 4 file errors

[nrc]

For the glorious future, my vision is that CompilationError is used for all errors in user code (and std lib functions), and KclError is only used for internal errors (due to bugs, or IO failure, etc.). This is pretty low priority and a lot of work because KclError is deeply integrated with control flow in the parser and executor. For all parts of the interpreter user errors should be collected rather than returned and we properly distinguish fatal and non-fatal errors.