唉我草rustc怎么还能这样坏掉

摘要：rustc以一种奇怪的方式坏掉了，现象是编译依赖树中所有用 quote! 宏的地方都会报错：

error[E0425]:cannot find value `value` in this scope

this error originates in the macro `$crate::guote_token_with_context` which comes from the expansion of the macro `quote`

起因

最近有人关注py32-hal的002B支持：PY32F002B support · Issue #34

年初的时候确实有个老哥（@sw）做了一一半的py32f002b，但是可能是因为芯片被锁了，没能得到他拉PR：Locking yourself out by reassigning the SWD pins

这次我就at sw，他说”I admit that I had lost interest for this”……于是我让sw先把pr拉了，我处理后面的工作。

在终于闲下来后，我把pr拉下来尝试编译：

py32-hal报了一些奇奇怪怪的依赖编译错误……

所有的用了quote!的crate全炸了

重新拉了py32-hal主分支，仍然是不能编译。

解决

之前github CI都过了，现在却怎么都编译不了了，今年六月的stable，和昨天的nightly都编译不过。

我首先怀疑的是依赖问题，比如某个crate本来是0.3.0，发上去一个有问题的0.3.1就会能让一堆人抓耳挠腮半天了。

defmt

我那时觉得嫌疑最大的是defmt。defmt的0.3.100事实上依赖了defmt 1.0。然后defmt又是在各种嵌入式底层crates被反复交叉依赖。同时，defmt也可能确实用了一些宏。

我将其固定到0.3.10，确保cargo tree里没有1.0.0的任何间接依赖了，也是无果。

我甚至怀疑是依赖攻击，即使用yank的方法导致的依赖问题……

缓存问题和Cargo.lock

通常来说cargo clean能解决一些问题，尤其是有C语言binding库的问题，因为rust编译缓存可能没法很好处理他们。

cargo update 能将所有依赖（尤其是使用git源的依赖）更新到最新。（比如Cargo.toml里某个crate B写0.3或0.3.9，都会更新到0.3.10）

而Cargo.lock能避免crateA的使用者的cargo把crate A的crate B更新到了0.3.10，而0.3.10事实上是个breaking change，导致用户没法用的情况。这主要是在bin工程中应用，用户可以加上--lock参数来强制使用Cargo.lock里写死的版本，来避免这个问题。

理论上说cargo update+clean已经能排除Cargo.lock限制的问题了（或者说Cargo.lock本身也不主动限制？），一阵折腾仍然是编译不过。

rust toolchain

群主肯定是喜欢我，toolchain都用我生日的😋

我切换到他测试的版本，仍然是错误……

08-12 19:12 依旧不行……好奇怪啊……

08-12 19:13 用stable也不行……

08-12 19:15 草了，好像找到原因了，我的rust坏了

因为现在我拐回去编译我今天下午刚写好的sifli-rs，也是这样的错误 ，刚才有一次rustup更新的时候，我不小心中断了

08-12 19:15

08-12 19:15 不是，为啥rustc还有这种坏法，天哪

08-12 19:16 后面重新更新和安装不同的工具链，都不行

08-12 19:16 明天又要重装rust了……

（就是说，在rustup更新某一toolchain的时候中断了，导致我其余所有的toolchain都坏了，新安装toolchain也不行，并且不报任何rustc有关的错误，而是报编译错误。第二天卸载重装rustup，才能编译……）