【官方讨论】2019年Rustc和RLS战略

官方主要考虑这些问题：

rustc如何帮助实现真正优秀的IDE体验？要达到这个目标，还需要考虑更多的子问题

• rustc如何才能更加易于维护和使用？
• 如何发展rustc的贡献者
• 如何提高rustc创新的步伐
• 如何解析和支持过程宏
• 如何将rustc暴露为更多的库

matklad 一直在重构libsyntax2的工作，将会非常适合过程宏和IDE

还需要改进rustc的增量编译支持，以配合IDE的响应时间。

更进一步提取像Chalk（trait系统）和Polonius（NLL借用检查器）这样的库，将rustc中复杂的问题，提取为单独的库，这些库倾向于遵循具有核心共享代码块以及进行单元测试的包装器的模式。但目前Chalk和Polonius还未投入使用。是否可以将MIR抽出来成为独立库？ 还有很多问题需要考虑。

对于RLS来说，未来可能考虑使用查询系统（Query System），希望有更快的响应时间，还必须考虑如何确保RLS得到良好的维护。

该帖子评论区还有很多Niko的想法，感兴趣可以去阅读

原文

---

模块系统更改已经进入FCP阶段

Rust 2018决定对模块系统进行简化，目前官方在测试它的两种形式：

• Anchored paths，其中use语句始终以外部包名称或关键字开头。 从子模块导入需要一个self::前缀
• Uniform paths，use语句也可以以本地项目名称开头

具体可以在Edtion Guide里查看.

原文

跟踪issues

---

请务必小心Travis的Rust缓存

Travis允许在.travis.yml中设置cache：cargo以启用Rust项目的缓存 缓存很棒：它避免了必须一直重建所有依赖项，从而加快构建速度。

travis文档说明了缓存：

请注意，我们的缓存不是网络本地，它仍然绑定到网络带宽和DNS解析。这会影响您可以存储在缓存中的内容。如果您在缓存中存储大于几百兆的存档，则不太可能看到速度大幅提升。

作者查看了他本地的缓存，大概有4.2G，可想而知，他的Travis缓存大概有5-7个GB之多。主要是因为Travis里缓存了target/ 和 .cargo/这些目录文件。缓存逐渐变大一般是两个原因：

• rustc是增量编译，其过程会产生大量的构建「副产品」，这些「副产品」会由Travis缓存，这些东西基本上没有用，但会积累。
• 过时的依赖库积累。有的库发了新版本，旧版本依旧会被Travis缓存。

解决办法：

• target /不值得缓存
• 〜/.cargo/bin/ 值得缓存
• 〜/ .cargo / registry / 不值得缓存

所以修改.travis.yml文件

# Need to cache the whole `.cargo` directory to keep .crates.toml for
# cargo-update to work
cache:
  directories:
    - /home/travis/.cargo

# But don't cache the cargo registry
before_cache:
  - rm -rf /home/travis/.cargo/registry

作者经过这样设置，Travis缓存下降到只有68M。

这个经验不一定适合你的项目，请看情况而定。

原文

---

Py-Spy: Python程序的抽样分析器。

可视化Python程序中耗费时间的部分，而无需重新启动程序或以任何方式修改代码，也不会以任何方式中断正在运行的程序。

py-spy

---

NeoVim/Vim的LSP支持

LanguageClient-neovim

---

• ( 每日新闻备份地址 )
• Telgram Channel ： https://t.me/rust_daily_news