Instead of checking recursively every possible object just check the
required keys for an object and validate it on construction or
assignment from json.
This will reduce the implementation effort for protocol extensions and
also reduce the false positives we might get if the protocol gets
updated.
Change-Id: I3df24e62430d2c7575d26c1581e6a9606e7da4c1
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
Fix MSVC2019
- result type of conditional expression is ambiguous:
types 'const char [1]' and 'QByteArray' can be converted
to multiple common types
Fix MinGW 8.1
- undefined reference to SemanticHighlightNotification::methodName
Fix Utils::transform with std::vector for GCC & MSVC
Unfortunately we cannot get rid of the special variant and optional
implementations, because Apple Clang requires deployment target >= 10.14
for the functions that can throw std::bad_optional_access.
Fixes: QTCREATORBUG-20520
Change-Id: I5c36a70f21f8b0215d2f4fc5c0653a022778d928
Reviewed-by: Christian Kandeler <christian.kandeler@qt.io>
Reviewed-by: Marco Bubke <marco.bubke@qt.io>
Reviewed-by: David Schulz <david.schulz@qt.io>
The proposal of SemanticHighlighting uses a versioned text document
identifier, but there is a suggestion to be more coherent with other
existing requests and use text document identifier instead (non versionned).
See here: https://github.com/microsoft/vscode-languageserver-node/pull/367/files#r225879268
The clangd language server implements the non versioned version.
Existing code was returning errors with clangd because
SemanticHighlightingParams::isValid would return false because of the
missing version field.
Change-Id: I1c36151342437adad2405118ca6b303db0936e41
Reviewed-by: David Schulz <david.schulz@qt.io>
The result of the document symbol request was a flat list of symbols
until version 3.10.0 of the Protocol. The new result type also added
whether a symbol is deprecated and what text should get selected
when a symbol is activated in the IDE UI.
Change-Id: Id30366c44198434c240f3a21b8b237bf6819a425
Reviewed-by: Christian Stenger <christian.stenger@qt.io>
The language server protocol is used to transport language specific
information needed to efficiently edit source files. For example
completion, go to operations and symbol information. These information
are transferred via JSON-RPC. The complete definition can be found under
https://microsoft.github.io/language-server-protocol/specification.
This language server protocol support consists of two major parts, the
C++ representation of the language server protocol, and the client part
for the communication with an external language server.
The TypeScript definitions of the protocol interfaces are transferred to
C++ classes. Those classes have getter and setter for every interface
value. Optional values from the protocol are represented by
Utils::optional<ValueType>. The JSON objects that are used to transfer
the data between client and server are hidden by a specialized
JsonObject class derived from QJsonObject. Additionally this JsonObject
provides a validity check that is capable of creating a detailed error
message for malformed, or at least unexpected JSON representation of the
protocol.
The client is the interface between Qt Creator and language server
functionality, like completion, diagnostics, document and workspace
synchronization. The base client converts the data that is sent from/to
the server between the raw byte array and the corresponding C++ objects.
The transportat layer is defined in a specialized base client (this
initial change will only support stdio language server). The running
clients are handled inside the language client manager, which is also
used to connect global and exclusive Qt Creator functionality to the
clients.
Task-number: QTCREATORBUG-20284
Change-Id: I8e123e20c3f14ff7055c505319696d5096fe1704
Reviewed-by: Eike Ziller <eike.ziller@qt.io>
