主要内容总结:
- toml v0.9 特性:近完全重写,性能大幅提升,支持
no_std
,还有其他改进。过去 3 个月专注于此实验,目标是提升 TOML 解析性能,如解决cargo publish
中Cargo.toml
解析开销大的问题,对比不同版本解析时间,新的toml v0.9
性能显著提升。 - 格式挑战:TOML 更面向人类,语法结构与 JSON 不同,如有序无关子表、特定表语法组合规则等,
toml v0.9
延续toml_edit
的方法,提供逻辑DeTable
进行解析。 - Cargo 需求:
cargo
曾用toml v0.5
解析Cargo.toml
,cargo add
引入toml_edit
后,需解决两个不同解析器的兼容性问题,确保性能不下降,toml_edit
用于解析--config key=false
表达式等,toml
需保留特定特性以满足cargo
需求。 - 实现细节:
toml v0.5
有易错令牌器,v0.6
直接解析字节到Table
,v0.9
有无误令牌器,通过回调报告解析事件和错误,构建DeTable
。 次要目标:
- 错误恢复:像
rustc
一样报告更多错误,通过&mut dyn ErrorSink
参数,避免回溯,目前仅在toml
中通过DeTable::parse_recoverable
暴露。 - 大整数支持:之前解析整数为
i64
,现在跟踪验证后的规范化字符串,用户可直接解析获取原始部分。 - no_std 支持:设计
toml_parser
支持core
,在资源受限系统中,可控制解析过程和标量值验证。 - facet:
facet-toml
基于toml_edit
,toml
更新为直接将serde
转换为toml_writer
,减少依赖。 - 减少 TOML 解析器的扩散:有多种 TOML 解析器,转向
toml
基于toml_edit
是正确的,可协作改进toml_parser
底层。
- 错误恢复:像
- 关于解析组合子:重写基于解析组合子的解析器为手写解析器后,认为默认选择应是解析组合子,但此次重写因满足用户需求是值得的,通常最重要的是能交付成果。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。