1.99.0 的 rustc.exe 被杀毒软件标红
这篇帖子报告 Windows 上官方 rustc 1.99.0 的可执行文件被杀毒软件标成恶意。作者 ParamountPotato 2026 年 10 月 30 日发到 r/rust，采集时 13 分、36 条评论。
作者用的杀毒软件是 F-Secure。作者把同一份 rustc.exe 上传到 VirusTotal，写有多家厂商也标成恶意。帖子给出的 SHA-256 是 FC40F1C8B65095A22A48C111AADC279C26A049B7E4161E8B99FFE3EB23873E86。
作者写，这个问题看起来只出现在 1.99.0，1.99.1 没有被标。复现步骤是新装 rustup，清空 RUSTUP_HOME 和 CARGO_HOME，再执行 rustup toolchain install 1.99.0-x86_64-pc-windows-msvc。rustup 安装器本身没有被标。装好的 1.99.0 rustc.exe 上传到 VirusTotal 会被标。1.99.1 安装后没有检出。
评论里，Erelde 写这个 SHA-256 是对的，并写杀毒软件经常对开发工具报误报。作者在评论里写，VirusTotal 概览显示这份可执行文件没有签名。帖子里没有 Rust 项目的官方说明。
原文链接：https://www.reddit.com/r/rust/comments/1xj8wlq/rustc_1990_windows_exe_flagged_as_malicious/
sysinfo 刷新 GPU 少跑 65% 指令
这篇博客记录 sysinfo 在 Linux 上加上进程 GPU 信息之后，怎么把刷新变慢的部分压回去。作者 imperioland 2026 年 10 月 30 日发到 r/rust，采集时 41 分、4 条评论。文章写，带这个 GPU 功能的 sysinfo 0.40.0 已在发帖前几小时发布。
GPU 相关文件的路径以 /dev/dri/ 或 /dev/accel/ 开头。作者先对 fd 做 readlink，只读这两类文件。不过滤时，1829 个进程、24,298,834,017 条指令、2.413956046 秒。过滤后，1871 个进程、2,131,000,470 条指令、0.442752139 秒。按耗时算，不过滤大约慢 5 倍。加上 GPU 功能之前，1860 个进程、514,120,617 条指令、0.107879757 秒。作者写，新的 GPU 路径比这慢 4.4 倍。火焰图里，readlink 占 49%，ReadDir::next 大约占 16%。
#1719 改用 getdents64 一次多读目录项，并把能换的 readlink / open 换成 readlinkat / openat。相对加 GPU 之前，慢的倍数从 4.4 降到 3.5。#1720 把一批 &str 换成 &[u8]。这条测量关掉了 GPU 刷新：指令从 61,010,201 降到 48,441,889，大约少 20%。#1756 复用读文件、拼路径和 getdents64 的缓冲区。分配次数从 205,755 降到 169,911，分配字节从 192,068,498 降到 39,452,116，分别少 17% 和 79%。运行时间没有变化。
最大的一跳在 #1768。Linux 上线程默认和父进程共用 fd 表，所以看 fd 分不出是哪个线程在用 GPU。线程可以用 unshare 拆开 fd 表，也可以用 kcmp 的 KCMP_FILES 检查。和父进程共用 fd 表的线程，直接复制父进程的 GPU 时间。改之前，2110 个进程、1,461,784,011 条指令、0.311808795 秒。改之后，2120 个进程、508,633,342 条指令、0.110293914 秒。指令少 65%，耗时少 64%。
0.40.0 还在 #1767 删掉了 set_open_files_limit。作者测到的差距在噪声范围内。
原文链接：https://blog.guillaume-gomez.fr/articles/2026-10-30+sysinfo%3A+fixing+performance+to+retrieve+process+GPU+usage
sanstun 把 WireGuard 加密拆出去
sanstun 是 Firezone 发布的 Rust WireGuard 状态机库，IO 和时间都留在库外面，加密可以放到别的线程做。作者 wh33zle 2026 年 10 月 30 日发到 r/rust，采集时 20 分、1 条评论。仓库是 firezone/sanstun。
Firezone 之前用 boringtun。他们的 fork 上，不算依赖升级，有 70 多个 PR。其中 firezone/boringtun#5 把时间改成调用方传入。库里也不再自己缓冲数据包。
入站数据报只有 Interface::receive 这一个公开解析入口。它解析报文、做限速，再交出对应的消息类型。握手 initiation 的构造函数是 crate 私有的，调用方拿不到绕过限速的入口。限速按源 IP 计，作用范围是整个 WireGuard interface，不按单条 tunnel 分开。WireGuard 报文有 4 类：handshake init、handshake response、cookie reply、加密数据。数据报用 ChaCha20-Poly1305。
Tunnel::begin_encapsulate 不加密。它检查当前 session，占一个包序号，推进计时器，返回 PendingEncapsulate。这个类型实现了 Send，可以交到别的线程再调用 encrypt。解密分成 begin_decapsulate、decrypt、commit_decapsulate。
cargo bench data_path 的 64 字节结果：begin_encapsulate 20.785–20.869 纳秒，encrypt 226.15–226.29 纳秒，begin_decapsulate 37.600–37.744 纳秒，decrypt 205.78–205.87 纳秒，commit_decapsulate 17.486–17.575 纳秒。1280 字节时，begin_encapsulate 还是 20.785–20.869 纳秒，encrypt 933.49–933.59 纳秒，decrypt 914.81–914.97 纳秒，commit_decapsulate 17.657–17.764 纳秒。1280 字节时，发出一个新包的记账部分只占加密时间的 2%。文章写，把加密挪到工作线程，理论上限大约 45 倍，这没有算线程交接的开销。
原文链接：https://www.firezone.dev/blog/introducing-sanstun
wasm 语言工具打开 408MB 文件少用内存
wasm-language-tools 是 WebAssembly 文本格式的语言服务器。v0.12.0 改了重命名、补全、格式化和解析性能。作者 gplane 2026 年 10 月 30 日发到 r/rust，采集时 1 分、1 条评论。
打开一个 408MB 文件，Linux 7.2、i7-12700K 上内存从 4.3GB 降到 1.65GB。macOS 15、M4 Mac mini 上从 4.0GB 降到 1.47GB。
解析器基准里，408,589,102 字节的 swc 文件从 3.0556–3.0595 秒降到 960.91–961.58 毫秒，吞吐从 127.36–127.52 MiB/s 升到 405.23–405.51 MiB/s，耗时变化是 -68.584% 到 -68.538%。900 字节样本从 12.149–12.169 微秒降到 8.7789–8.7914 微秒，耗时变化是 -27.855% 到 -27.600%。textDocument/foldingRange 改用 amber tree 之后快 92%。
重命名时，非法标识符会加上双引号收下。缺前导 $ 时会补上。指令名补全只列前缀，再输入 . 才会继续展开。范围格式化只改选中范围，不改整个语法节点。SyntaxNode 和 SyntaxToken 现在带生命周期，这是破坏性改动。
原文链接：https://github.com/g-plane/wasm-language-tools/releases/tag/v0.12.0
From Rust中文社区 Mike
社区学习交流平台订阅：
评论区
写评论还没有评论