Multiple LS server instances per workspace

[ghentschke]

This PR would be a basic implementation for #43

[ghentschke]

I think there is no certain need to run one language server per C/C++project, because clangd determines the respective compile_comands.json for each project file. Either by defining a path to it in a .clangd file in the source folder or by copying the compile_commands.json from build folder into the source tree after building. These actions should be part of the toolchain and/or builder.
The current bug is, that the compile_commands.json used when opening a file outside of the project (e.g. standard lib header) is not always inferred from the right project file. We need a strategy for this here.

[ruspl-afed]

If this class was an OSGi component, it could just bind required IWorkspace service

[ghentschke]

It seem to be not a simple add:

 @Reference
 private IWorkspace workspace;

does not work. (from doc https://help.eclipse.org/latest/nftopic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/core/resources/IWorkspace.html)

[ghentschke]

also when adding @ Component:

@Component
public class PropertiesCompileCommandsDirLocator implements ICompileCommandsDirLocator {
	@Reference
	private IWorkspace workspace;

I think it has something to do how the class is instantiated by org.eclipse.core.runtime.IConfigurationElement.createExecutableExtension(String)

[ruspl-afed]

It seem to be not a simple add

Yes, you are right, it requires a bit deeper redesign. We need to:

1. define an interface that does what we need
2. provide implementation for this interface via @Component
3. obtain in instance of this interface and use it

For 1) I would expect an interface that has a method similar with current LSPPlugin#getCompileCommandsDirLocators, like

public interface CompileCommandsLocations {

   List<CompileCommandsLocation> locations();
}

that uses

public interface CompileCommandsLocation {

   Optional<IPath> resolve(URI document);

}

Then 2) in this case we may add one component to implement CompileCommandsLocations (currently it is CompileCommandsDirLocatorRegistry) and a few components to implement CompileCommandsLocation (currently it is PropertiesCompileCommandsDirLocator). We may optionally keep extension point as an alternative way to fulfill CompileCommandsLocations

And, 3) we can use ServiceCaller to interact with an instance of CompileCommandsLocations interface. No need to have these public synchronized methods in *Plugin classes. No need to obtain and keep an instance of IWorkspace

[ruspl-afed]

Here we have a mix of low level OSGi API with public accessors to stateful activator. It looks more consistent to use OSGi components for CLanguageServerRegistry and CompileCommandsDirLocatorRegistry

[ghentschke]

I've to find a solution for opening external files (e.g. system header files) which will be opened by LSP4E in case of a Go-to-declaration event (F3). Currently LSP4E starts a new server for every external file. This server has no idea where to find a compile_commands.json since there is no in the system include path. My initial approach to change the LSP4E behavior in a way that external files will be opened in the same server context as the origin file has been rejected, because it's too server specific.

A possible solution has been proposed here by @ddscharfe

[ruspl-afed]

This PR would be a basic implementation for #43

Shouldn't it go to PR description?

[ruspl-afed]

@ghentschke should I try to restart this work using current state of the code?

[ghentschke]

should I try to restart this work using current state of the code?

Any work is appreciated here! As I wrote yesterday, there should be some work done on LSP4E to support multiple language server properly. See LSP4E issue #694

[ghentschke]

A solution for the singleton attribute in the LSP4E LS definition extension might be, to define 2 LS: one singleton and one not singleton. They should be interlocked so that only one server definition is enabled at once.
The decision could be linked to the Enable project-specific settings and Prefer C/C++ Editor (LSP) flags in the project properties. If the flags are set, the non-singleton server definition is used. Otherwise not.

The external file problem for multiple servers could be solved by setting the path to the compile_commands.json in the clangd initializationOptions : https://clangd.llvm.org/extensions#compilation-commands

[ruspl-afed]

@ghentschke is it still relevant?

[ghentschke]

@ghentschke is it still relevant?

No, I think this feature has actually a very low priority. And I cannot see any advantage of multiple LS per workspace anymore.