小编Fed*_*ico的帖子

cargo当编译由多个包组成的 Rust 工作区时，当包的成功编译foo依赖于其依赖项未启用的功能时，是否有办法出错？foo

让我举一个具体的例子。使用下面描述的工作区cargo build会成功，但cargo build -p foo会出现编译错误，因为tokio中缺少功能foo/Cargo.toml：

error[E0432]: unresolved import `tokio::io::AsyncWriteExt`\n --> foo/src/lib.rs:1:5\n  |\n1 | use tokio::io::AsyncWriteExt;\n  |     ^^^^^^^^^^^-------------\n  |     |          |\n  |     |          help: a similar name exists in the module: `AsyncWrite`\n  |     no `AsyncWriteExt` in `io`\n\nFor more information about this error, try `rustc --explain E0432`.\nerror: could not compile `foo` due to previous error\n

这不好！cargo build愉快地接受间接依赖的用法。也就是说，更改既不在 …

我有时会 看到 Rust crate有一个名为的文件夹systest.我想这个名字代表"系统测试",但我找不到任何这方面的文档.

我的问题是:

• 一个目的是systest什么？只是测试一个箱子编译好,或者测试另一个箱子里的某些代码运行正常？
• 写作时要遵循的规则是systest什么？它只是一个文件夹中的箱子systest吗？
• 为什么lib.rsin systest/src似乎总是包含all.rs从中生成的文件build.rs？

我收到以下生命周期错误:

error[E0495]: cannot infer an appropriate lifetime for autoref due to conflicting requirements
  --> prusti-viper/src/procedures_table.rs:42:40
   |
42 |         let mut cfg = self.cfg_factory.new_cfg_method(
   |                                        ^^^^^^^^^^^^^^
   |
note: first, the lifetime cannot outlive the anonymous lifetime #1 defined on the method body at 40:5...
  --> prusti-viper/src/procedures_table.rs:40:5
   |
40 | /     pub fn set_used(&mut self, proc_def_id: ProcedureDefId) {
41 | |         let procedure = self.env.get_procedure(proc_def_id);
42 | |         let mut cfg = self.cfg_factory.new_cfg_method(
43 | |             // method name
...  |
135| …