跳转至

寻求帮助

部分内容引用修改自 寻求帮助

写 Rust 时遇到编译错误怎么办

初学 Rust 的时候，经常会遇到一个问题：自己觉得为了实现某个功能，应该用 A 写法，但是写到中间，遇到了编译错误，自己也没仔细看编译错误是什么，就看到 VSCode 显示红色下划线，或者看了错误信息但是没看懂，觉得 A 写法是错的，于是就去尝试貌似正确实际错误的 B 写法，结果又出现了新的编译错误，到最后就不知道怎么写了。

这可能是以前学习 C/C++ 的习惯：在 C/C++ 中，特别是 C，熟练以后其实是不容易遇到编译错误的，大多数是逻辑上的问题，因此遇到编译错误，就会下意识觉得不能这么写，把代码删掉。

但是在 Rust 中不一样：Rust 的编译期错误很多，所以很有可能发生上面说的情况，本来在正确的道路上走，结果遇到了编译错误就退缩了，走到了错误的道路上去。

但很多时候，Rust 编译错误并不是说你写的思路是错的，而是你写的代码没有满足 Rust 严格的要求。

你需要做的是跟随编译器的指示（很多时候错误输出里会提示你该怎么改），而不是回避它，删掉自己刚写的代码。

遇到问题时怎么办

  1. 尝试阅读并理解错误信息，不要因为全是英文就觉得一定看不懂
  2. 用错误信息上网搜索解决方法，并且进行尝试
  3. 尝试寻求 LLM(Large Language Model) 的帮助，并参考尝试它给出的解答
  4. 查询错误所涉及的函数的相关文档，和样例代码进行比对
  5. 学会调试器，单步查看每一步变量的变化（裸内核调试可能会遇到一些困难，如果发生了自己不可理解的错误，可以在课程群里寻求帮助）
  6. 如果实在自己解决不了，在找别人求助之前，先用电脑截图关键部分和错误信息；如果代码多的话，把关键的代码放到 pastebin 服务上生成一个链接
  7. 如果可以的话，尽量缩减代码，得到一个 MWE（最小错误样例），这样可以方便他人复现问题
  8. 向别人阐述你的问题，表述你都做了哪些尝试，并且把代码和错误信息截图（或者链接）发给对方

关于操作系统开发的问题，我总是找不到合适的信息，LLM 也总是胡言乱语，怎么办？

OS 开发在互联网上的资料相对较少或较为古老，因此在遇到问题时，你可能找不到合适的资料。

一个比较好的推荐是优先尝试在 OS Dev 上寻找相关的词条，也可以参考 See Also 中的链接。

同时，在实现某些驱动或文件系统的时候，由于是规范化的步骤，也可以在 Github 上搜索相关的项目和驱动代码。

这里不要局限于 Rust 语言，有必要时可以参考 C/C++ 的实现。

如果存在代码引用和参考，请务必在代码注释中注明出处。

对于驱动的引用，可以在文件开头使用 //! 风格的注释，将你参考的链接放在注释中。

例如：

1
2
3
4
//! ATA Device Driver
//!
//! reference: https://wiki.osdev.org/IDE
//! reference: https://wiki.osdev.org/ATA_PIO_Mode

完整版：见 《提问的智慧》，也可阅读一生一芯项目书写的《如何科学地提问》。

避免 X-Y 问题

提问时需要避免 X-Y 问题：即你实际遇到了 X 问题，你认为 X 问题要用 Y 方法解决，在实现 Y 方法时遇到困难，然后向他人提问如何实现 Y 方法。但很多时候 Y 方法并不是 X 问题的正确解法，此时可能会得到错误的答案。引用 X-Y Problem 的一个例子：

  • X 问题：想要截取文件名的后缀名
  • Y 方法：截取文件名的后三位字符
  • 此时的 Y 方法并不是解决 X 问题的正确方法，因为后缀名不一定是三个字符
  • 正确的 X 问题的解法是找到最后一个 .，然后提取它之后的字符
  • 如果提问的时候只提及了 Y 方法，而没有 X 问题，就会出现这样的问题

因此在提问时，为了避免 X-Y 问题，建议按照下面的模板来描述完整的问题：

  • 我正在做 X 问题
  • 我认为为了解决 X 问题，可以用 Y 方法
  • 在解决 X 问题时，采用了 Y 方法，过程中遇到了 Z 问题，尝试用 A 方法解决，但是没有效果

而不是：

  • 我遇到了 Z 问题，求救 T_T