Introduction to language server

[anfsity]

Sorry for the late pr, I forgot about it ⊙﹏⊙∥

[anfsity]

I write a devcontainer template:

{
  "name": "SysY Compiler Dev",
  "build": {
    "dockerfile": "../compiler-dev/docker/Dockerfile",
    "context": "../compiler-dev/docker"
  },
  
  // Keep the container workspace path identical to the local path
  // This helps tools like clangd and CMake resolve absolute paths correctly
  "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind",
  "workspaceFolder": "${localWorkspaceFolder}",

  "customizations": {
    "vscode": {
      "extensions":[
        // C/C++ Language Server (Provided by LLVM)
        "llvm-vs-code-extensions.vscode-clangd",

        // --- OPTIONAL: CMake build system integration ---
        // This project supports BOTH `make` and `cmake`. 
        // If you prefer using CMake, uncomment the following two extensions:
        // "ms-vscode.cmake-tools",
        // "twxs.cmake",
        // If you want to install new extensions, simply paste the VS Code extension ID here.

        // Syntax highlighting for SysY / Lex & Yacc
        "daohong-emilio.yash",
        "mikawi.flex-language"
      ],
      "settings": {
        // Configure clangd for a better C++ IDE experience
        "clangd.arguments":[
          // Specify where clangd can find the compile_commands.json.
          // If you use CMake and build your project in the `cmake-build` directory, 
          // the generated compilation database (cdb) will be located there by default.
          // In other words, you should change this path to match your actual CMake build directory.
          "--compile-commands-dir=${containerWorkspaceFolder}/cmake-build",
          "--background-index",
          "--j=12",
          "--completion-style=detailed",
          "--header-insertion=never",
          "--clang-tidy",
          "--inlay-hints=true",
          "--fallback-style=LLVM"
        ]

        // --- OPTIONAL: CMake build directory ---
        // Uncomment the line below if you choose to use CMake.
        // This option is used by the CMake extension (though honestly, the VS Code CMake extension isn't that great to use).
        // "cmake.buildDirectory": "${workspaceFolder}/cmake-build"
      }
    }
  },

  // Use the default non-root user created by Ubuntu base image
  "remoteUser": "ubuntu",

  // Add standard development utilities automatically
  "features": {
    "ghcr.io/devcontainers/features/common-utils:2": {
      "username": "ubuntu",
      "userUid": "automatic",
      "userGid": "automatic"
    }
  },

  // Essential privileges for C/C++ debugging (GDB)
  "runArgs":[
    "--network=host",
    "--cap-add=SYS_PTRACE",
    "--security-opt",
    "seccomp=unconfined"
  ]
}

what do you think?

[MaxXSoft]

感谢 PR！无需担心时间问题，没那么着急😂

[MaxXSoft]

感谢更新！

除了 LSP 以外，你试过用 Dev Containers 直接在容器里调试吗？这样 VS Code 是不是还需要装 CodeLLDB 之类？

[MaxXSoft]

关于模板，因为我没用过 Dev Containers，所以有几个问题需要请教下：

1. "build": { "dockerfile": "../compiler-dev/docker/Dockerfile", "context": "../compiler-dev/docker" } 这里必须引用 Dockerfile 吗？这么做的话，读者还必须 clone compiler-dev 仓库，有点复杂。
2. workspaceMount 的部分如果挂成和本机完全一样，在 Windows 路径上会出现问题吗（盘符之类）？遇到目录带空格或者有其他奇怪字符会出问题吗？能否在容器里使用固定路径，然后用其他方式来让 clangd 正常工作？
3. settings 里写死 --j=12 对没那么多核心的 CPU 来说不太友好，能让 clangd 自己推导并行度吗？
4. --compile-commands-dir 这块可能需要额外说明，比如告诉大家怎么设置这个路径。
5. runArgs 里的 --network=host 是必需的吗？去掉会有什么问题？

[anfsity]

其实 devcontainer 不是必要的，我之前用它是因为 cpp 的 module 得 BMI 对齐。clangd 为了提供支持 module 的服务，会读取构建系统生成的 .pcm，但是我宿主机上的 clangd 读取容器内部生成的 pcm 时，会因为签名不一致报错，所以得使用容器内部 apt 同源的 clangd（ 在我引入 module 之前，使用 host 上的 clangd 一直都是工作的很好的。

• 在容器内直接调试是可行的。
• build 那一节是我用来本地调试用的，到时候可以直接换成 dockerhub 上镜像。
• workspaceMount 我还没有在 windows 上测试过，等会我看看。不过像我这样写的话，确实有可能导致问题。
• --j=12 是可以修改成让 clangd 自己推导的。
• 我会补上 --compile-commands-dir 的说明的。
• runArgs 里的 --network=host 不是必须的，当初是我遇到了容器内部的一个网络问题才加上的。我现在使用插件的话，不需要这个也能工作。

我有段时间没用这个了，把当初用的配置随便修改了一下，没有考虑全面 😭

[MaxXSoft]

没关系，慢慢来，这个事情不必着急。

你提到：

其实 devcontainer 不是必要的，我之前用它是因为 cpp 的 module 得 BMI 对齐。clangd 为了提供支持 module 的服务，会读取构建系统生成的 .pcm，但是我宿主机上的 clangd 读取容器内部生成的 pcm 时，会因为签名不一致报错，所以得使用容器内部 apt 同源的 clangd（ 在我引入 module 之前，使用 host 上的 clangd 一直都是工作的很好的。

我有些困惑：你希望开发环境集成 clangd，只是为了解决你提及的这个问题吗？这种问题在其他同学们的实践流程中是否普遍？

我的想法是：如果要引入 clangd，最好能有一个站得住脚的理由，比如它可以让大家开发的过程更方便之类。不过我没研究过 clangd 在这个流程里能干嘛，所以我希望能从你之前的实践中学习到一些经验。

之前我一直想在教程中介绍如何把 VS Code 的调试功能集成到开发环境里的部分，让大家能直接在 Docker 容器里下断点调试。我觉得这部分对使用体验的提升是很有必要的。如果 clangd 能解决类似的痛点，那还是很不错的。

[anfsity]

是的，这个问题恐怕非常少见，不是所有同学都像我一样会去追求 cpp 新特性（

不过，光就 clangd 本身而言，其提供的跳转定义，查找引用等功能在开发中我觉得是十分方便甚至不可缺少的。引入 clangd 的话，我能想到的好处只有改善 c/c++ 开发体验。其生态位和 rust-analyzer 是一样的。

如果要集成调试功能的话，我觉得 Dev Containers 插件是可以做到的，他可以提供一个可复现的配置完善的 VScode 环境，如果再提供 launch.json，我认为是可以做到开箱即用的。