rustc处理cfg的流程及cfg_attr转feature的实现方式咨询

一、具体位置与实现方式 #

• 核心逻辑在rustc的rustc_expand组件里，对应expand_cfg_attr函数（代码路径大致为rustc_expand/src/cfg.rs，不同版本可能略有调整）。
• 当编译器碰到#![cfg_attr(target_os = "macos", feature(...))]时，会先评估target_os = "macos"这个条件：通过查询当前编译目标的环境信息判断是否满足。如果符合条件，就直接把feature(...)展开成 crate 根属性#![feature(...)]；不符合就直接丢弃这个属性。
• 这个展开属于语法扩展早期步骤，在类型检查、代码生成之前完成，保证后续的feature gate检查能正确识别启用的nightly特性。

二、rustc处理cfg的流程提示 #

• 语法解析与属性收集
  编译器先把源码解析成AST，同时收集所有属性（包括cfg、cfg_attr），此时cfg_attr还保持原始结构，没展开。
• 条件属性展开
  进入语法扩展阶段专门处理这类宏属性：
  • 先解析cfg条件（比如target_os、debug_assertions），通过rustc_target组件获取当前编译目标的元数据，判断条件是否成立。
  • 条件成立的话，就把cfg_attr包裹的内部属性（比如feature）注入到对应AST节点；不成立就忽略该属性。
• 后续阶段的cfg处理
  展开完成后，类型检查、代码生成等后续阶段会基于展开后的代码和属性处理，比如feature gate检查会扫描所有展开后的#![feature(...)]，确认是否是允许的nightly特性。
• 实用验证方法
  可以用rustc -Z unpretty=expanded命令查看编译前展开后的完整代码，直接确认cfg_attr是否被替换成了feature属性。

内容的提问来源于stack exchange，提问作者Yinwhe