编程语言服务器协议 已翻译 7%

oschina 投递于 11/08 12:12 (共 14 段)
阅读 51
收藏 0
0
加载中

上个月,Apple 在 Swift.org 论坛上宣布,它正在开始采用 Swift 和 C 语言的语言服务器协议(LSP)

在 Apple,我们优先考虑为所有 Swift 开发者提供高质量的工具,包括那些在不在 Apple 平台上开发的开发者。我们希望和开源社区合作并且集中精力建设可以由 Xcode 和其他编辑器和平台共享的公共基础设施,因此,我们选择采用 LSP。

Argyrios Kyrtzidis,2018年10月15日

工匠驿站
工匠驿站
翻译于 11/09 18:39
0

This is arguably the most important decision Apple has made for Swift since releasing the language as open source in 2014. It’s a big deal for app developers, and it’s an even bigger deal for Swift developers on other platforms.

To understand why, this week’s article will take a look at what problem the Language Server Protocol solves, how it works, and what its long-term impacts may be.

Imagine a grid with each row representing a different programming language (Swift, JavaScript, Ruby, Python, etc.) and each column representing a different code editor (Xcode, Visual Studio, Vim, Atom, etc.), such that each cell represents the level of support that a particular editor has for a language.

已有 1 人翻译此段(待审批)
我来翻译

Up until recently, what you’d find was a patchwork of compatibility across the various combinations. Some editors offered deep integration with a few languages and little to no support for anything else, whereas other editors aimed to be general-purpose with at least a modicum of support for many languages. (The term IDE is often used to describe the former.)

Case in point: You’d be stubborn not to use Xcode for app development and foolish to use it for anything else.

For an editor to have better support for a particular language, it needs to write integration code — either directly in the code base or via a plugin system. Due to implementation differences across languages and editors, improvements to, say, Ruby support in Vim wouldn’t translate into better support for Python, nor could they be applied to make Ruby work better in Atom. The end result: inconsistent support across technologies and a lot of wasted effort.

The situation we described is often referred to as an M × N problem, where the number of integrations is the product of M editors and N languages. What the Language Server Protocol does is change this M × N problem into a M + N problem.

已有 1 人翻译此段(待审批)
我来翻译

Rather than an editor having to implement support for each language, it only needs to support the LSP. And in doing so, it gets the same level of functionality for all languages that support the LSP.

An essay from 2010 by Tomohiro Matsuyama entitled “Emacs は死んだ” (“Emacs is Dead”)offers a nice encapsulation of this problem. Describing the limitations of Emacs’ scripting language (no multi-threading, few low-level APIs, and a small user base) Matsuyama argues that the preferred approach to writing a plugin should be to interface with an external program rather than implement something natively.

已有 1 人翻译此段(待审批)
我来翻译

Language Server Protocol provides a common set of functionality for supported languages, including:

  • Syntax Highlighting

  • Automatic Formatting

  • Autocomplete

  • Syntax

  • Tooltips

  • Inline Diagnostics

  • Jump to Definition

  • Find References in Project

  • Advanced Text and Symbol Search

Rather than reinventing the wheel for each new technology, tools and editors can invest in better usability and more advanced functionality.

已有 1 人翻译此段(待审批)
我来翻译

How Language Server Protocol Works

If you’re an iOS developer, you may be most familiar with the terms server and protocol in the sense of communicating with web applications in JSON format via HTTP. This actually isn’t too far off from how the Language Server Protocol works.

In the case of LSP, the client refers to the editor — or more generally, the tool — and the server refers to an external program run locally in a separate process.

As for the protocol itself, LSP resembles a simplified version of HTTP:

  • Each message consists of a header part and a content part.

  • The header part has a required Content-Length field containing the size of the content part in bytes, and an optional Content-Type field (application/vscode-jsonrpc; charset=utf-8 by default)

  • The content part uses JSON-RPC to describe the structure of requests, responses, and notifications.

已有 1 人翻译此段(待审批)
我来翻译

Whenever something happens in the tool, such as the user jumping to the definition of a symbol, the tool sends a request to the server. The server receives that request and then returns an appropriate response.

For example, imagine that a user opens the following Swift code in an Xcode-like editor that supported the Language Server Protocol:

Swift

class Parent {}
class Child: Parent {}

When the user ⌘-clicks the symbol Parent in the inheritance clause on line 2, the editor jumps to the definition of the Parent class on line 1.


已有 1 人翻译此段(待审批)
我来翻译

Here’s how LSP enables this interaction behind the scenes:

First, when the user opens the Swift code, the editor launches its Swift language server in a separate process, if it isn’t running already, and performs any additional setup.

When the user executes the “jump to definition” command, the editor sends the following request to its Swift language server:

JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "textDocument/definition",
  "params": {
    "textDocument": {
      "uri": "file:///Users/NSHipster/Example.swift"
    },
    "position": {
      "line": 1,
      "character": 13
    }
  }
}

已有 1 人翻译此段(待审批)
我来翻译

Upon receiving this request, the Swift language server uses a compiler tool like SourceKit to identify the corresponding code entity and find the location of its declaration on the preceding line. The language server then responds with the following message:

JSON

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "uri": "file:///Users/NSHipster/Example.swift",
    "range": {
      "start": {
        "line": 0,
        "character": 6
      },
      "end": {
        "line": 0,
        "character": 12
      }
    }
  }
}

Finally, the editor navigates to the file (which, in this case, is already open), moves the cursor to that range, and highlights the token.

The beauty of this approach is that the editor did all of this without knowing anything about the Swift programming language other than that .swift files are associated with Swift code. All the editor needs to do is talk to the language server and update the UI. And knowing how to do that, the editor can follow the same procedure to facilitate this interaction for code written in any language with a language server implementation.

还没有人翻译此段落
我来翻译

Language Server Protocol Support in Clang / LLVM

If the M + N diagram from before looks familiar, it might be because it’s the same approach taken by LLVM.

At the core of LLVM is an intermediate representation (IR). Supported languages generate IR using a compiler frontend, and that IR can generate machine code for any platform supported by a compiler backend.

If you’re curious to learn more about how Swift code is compiled, check out our article about SwiftSyntax.

还没有人翻译此段落
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(0)

返回顶部
顶部