Foundry Forge Lint 深入解析unused-return 规则与外部调用返回值丢弃检测【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本文以 Foundry 仓库中forge-lint的unused-return规则文档crates/lint/docs/unused-return.md为核心结合其 Rust 实现与测试用例系统讲解该静态检查的检测范围、判定原理、修复方式与边界行为帮助 Solidity 开发者将这一规则正确接入日常合约审计与 CI 流程。unused-return是 Foundry 内置forge-lint静态分析器位于crates/lint中一条**中等严重度Med**的 Solidity 检查规则核心职责是识别高层外部调用返回了值却被整体丢弃的写法。丢弃返回值往往意味着应用层错误被静默吞掉或查询结果被无视是 DeFi 合约中一类典型隐患。读完本文你将掌握该规则的精确触发条件、源码级判定逻辑、与其姊妹规则erc20-unchecked-transfer的分工以及如何借助仓库内置测试用例理解各种边界情形。规则速览属性值规则 IDunused-return严重度Med说明文案return value of an external call is not used源码位置crates/lint/src/sol/med/unused_return.rs文档位置crates/lint/docs/unused-return.md测试用例crates/lint/testdata/UnusedReturn.sol 与 UnusedReturn.stderr在 lint 注册表中crates/lint/src/sol/med/mod.rs该规则以unused_return: (UnusedReturn, late, (UNUSED_RETURN))注册属于late pass——即在 Solar 完成语义分析、能够解析出函数类型与返回列表之后才运行的检查阶段。检测范围什么会被标记根据规则文档What it doesunused-return检测以下两类情况高层外部调用对接口、合约实例发起的外部external函数调用函数声明了返回类型但整个返回值被丢弃。外部库调用经由外部库library发起的、带有返回值的调用同样纳入检测。元组返回的缺槽当被调函数返回元组多返回值时只要任意一个槽位在解构赋值中被省略写成空位即使其余槽位被使用也会触发告警。同时文档明确了两类排除项ERC20transfer/transferFrom这两个函数虽然返回bool且常被裸调但被刻意排除在unused-return之外改由独立的高严重度规则erc20-unchecked-transfer专门负责详见后文与 erc20-unchecked-transfer 的分工。内部调用包括内部函数调用、库的内部调用以及经由基类限定qualified base-contract的内部调用均不触发本规则。为什么这是坏味道规则文档Why is this bad?给出的理由值得仔细咀嚼隐藏失败丢弃返回值会掩盖通过该返回值上报的应用层失败。很多合约并不通过 revert 报错而是以返回值如bool、状态码、价格是否有效等传递业务层面的失败信号。忽略查询结果把一次查询如预言机报价、余额、配置项的返回结果随手丢弃等于放弃了调用它的意义。文档特别澄清了一个常见误区高层外部调用即使丢弃返回值revert 依然会向上传播EVM 调用层级的失败不会被吞掉。因此本规则针对的并不是revert 被吞这一类问题而是成功返回后携带的信息被白白扔掉——这是一个语义层面的缺陷而非调用失败处理层面的缺陷。这一定位决定了它的严重度被定为Med而非High。源码级判定原理要精确理解触发条件需要读一下规则实现 unused_return.rs。其核心逻辑分为两层。第一层语句形态匹配check_stmtLateLintPass的check_stmt只对三类语句形态做进一步判断unused_return.rs#L23-L38let (call, span) match stmt.kind { StmtKind::Expr(expr) match expr.peel_parens().kind { // (x, ) call() with an ignored slot. ExprKind::Assign(lhs, None, rhs) if tuple_elems(lhs).is_some_and(|e| e.iter().any(Option::is_none)) { (rhs, expr.span) } _ (expr, expr.span), }, StmtKind::DeclMulti(vars, expr) if vars.iter().any(Option::is_none) { (expr, expr.span) } _ return, };纯表达式语句oracle.getPrice(t);这种裸调用语句整个表达式被当作语句丢弃。带缺槽的元组赋值(price, ) oracle.latest(t);左值元组中任意一个元素为None空槽。带缺槽的多变量声明(uint256 price, ) oracle.latest(t);声明列表中存在None元素。注意这里对左侧元组使用了tuple_elems(lhs)并检测Option::is_none正是元组返回有任意槽位被省略这一规则的直接落地。而不带缺槽的完整解构两个值都取不会进入该分支由后面的返回值使用分析放行。第二层调用性质判定is_unused_return_call拿到候选调用表达式后is_unused_return_call 做四步过滤必须是调用表达式需为ExprKind::Call且被调用方是成员访问ExprKind::Member即receiver.method(...)形态。必须是外部/委托调用函数类型通过gcx.type_of_expr解析出函数类型仅当TyFnKind::External或TyFnKind::DelegateCall时才继续。这是内部调用被排除的代码级依据——内部函数不属于这两种调用种类。必须能解析到函数定义gcx.resolved_function(callee)解析出函数 ID进而取得其声明f.returns。返回列表非空且非 ERC20 transfer!f.returns.is_empty() !is_erc20_transfer。换言之被调函数声明了至少一个返回值且不是被豁免的 ERC20 形态。ERC20 豁免的精确算法豁免判断unused_return.rs#L59-L68非常严谨它要求返回签名与参数签名同时匹配——transfer需为returns (bool) 参数(address, uint256)transferFrom需为returns (bool) 参数(address, address, uint256)且各参数、返回值均为基础类型is_elementary。这样既不会误伤恰好同名但签名不同的函数也保证了对标准 ERC20 形态的精确识别。触发示例与修复写法规则文档给出了标准对比例子完整如下。触发写法返回值被静默丢弃interface IOracle { function getPrice(address token) external returns (uint256); } contract Example { IOracle oracle; function updatePrice(address token) external { oracle.getPrice(token); // return value silently discarded } }推荐写法将返回值落盘或显式消费interface IOracle { function getPrice(address token) external returns (uint256); } contract Example { IOracle oracle; uint256 public lastPrice; function updatePrice(address token) external { lastPrice oracle.getPrice(token); } }修复思路与Why is this bad?一一对应把返回值赋给状态变量如lastPrice、传给require断言、或参与后续运算让成功调用的返回信息真正被使用。边界行为从测试用例看判定细节规则仓库内置了非常详尽的测试契约 UnusedReturn.sol文件头通过//compile-flags: --only-lint unused-return让测试仅启用本规则。逐条阅读可以提炼出以下边界语义~WARN注释即期望诊断与 UnusedReturn.stderr 中的 9 条告警一一对应触发应告警的场景场景代码形态说明uint256返回值被丢弃oracle.getPrice(t);最基础形态非 ERC20 的bool返回值被丢弃oracle.update();bool同样受检显式接口强转后调用IOracle(oracleAddr).getPrice(t);强转不影响判定重载函数命中有返回值版本oracleOverloaded.getPrice(t);同一名字下按签名解析只有选中版本有返回才触发命名参数调用oracle.getPrice({token: t});命名实参不影响元数判断括号包裹接收者(oracle).getPrice(t);/(IOracle(oracleAddr)).getPrice(t);peel_parens剥括号后仍判定元组解构含空槽声明式(uint256 price, ) oracle.latest(t);缺槽即告警元组解构含空槽先声明后赋值式(price, ) oracle.latest(t);同上放行不应告警的场景场景代码形态说明返回值存入局部变量uint256 price oracle.getPrice(t);捕获即视为已使用返回值直接参与表达式return oracle.getPrice(t);直接消费函数本身无返回值oracle.noReturn();returns为空不触发ERC20transfer/transferFromtoken.transfer(to, amt);移交给erc20-unchecked-transfer重载命中无返回值版本oracleOverloaded.getPrice(id);选中版本无返回元组完整解构且均被读取(uint256 price, bool ok) oracle.latest(t);无空槽捕获后分支读取if (cond) return price;只要有读取路径即视为使用注意最后两类good7–good10表明返回值捕获进变量后即使被覆盖、或仅在某个分支读取都算作已使用——该规则放行的粒度是调用结果是否被消费不做数据流层面的死代码分析避免误报。与 erc20-unchecked-transfer 的分工unused-return特意豁免 ERC20transfer/transferFrom是因为 Foundry 有更严厉的专门规则 erc20-unchecked-transfer严重度HighERC20 规范允许代币通过返回false而非 revert 来报告失败忽略bool会让失败的转账无声无息导致账目漂移并成为常见 DeFi 攻击面。两条规则的关注点差异总结如下维度unused-returnerc20-unchecked-transfer严重度MedHigh目标任意外部调用返回值的丢弃仅 ERC20transfer/transferFrom的bool未检查底层理由应用层失败/查询结果被吞ERC20 用返回值而非 revert 报告失败建议修复赋值给状态变量、参与运算require(...)断言或使用SafeERC20包装对应测试文件分别为 UnusedReturn.sol 与 UncheckedTransferERC20.sol。两者互补一个管返回值语义丢失一个管ERC20 特有失败信号被忽略。如何在项目中启用与验证unused-return随forge-lint内置提供无需额外安装插件。测试用例中使用--only-lint unused-return单独启用该规则便于在 CI 或本地对单一规则做聚焦检查正式项目中通常直接运行默认的forge lint让全部规则含本规则参与扫描即可。如需扩展验证该规则在自定义合约上的行为可以直接参考并复用仓库内的测试契约 UnusedReturn.sol——其中覆盖了重载、强转、命名参数、元组缺槽、ERC20 豁免等全部关键路径是理解规则边界最完整的活文档。小结unused-return是 Foundry lint 体系中一条语义清晰、边界精确的中等严重度规则它聚焦高层外部调用成功返回后的信息丢失通过语句形态匹配 函数类型解析两层判定实现并在源码与测试中严格划清了与erc20-unchecked-transfer的职责边界。理解其源码实现unused_return.rs与测试用例UnusedReturn.sol不仅能帮你准确修复告警也能避免过度修复——例如对 ERC20 转账的bool处理应交给高严重度的专用规则而不是在本规则下误伤。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Foundry Forge Lint 深入解析：unused-return 规则与外部调用返回值丢弃检测
Foundry Forge Lint 深入解析unused-return 规则与外部调用返回值丢弃检测【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry本文以 Foundry 仓库中forge-lint的unused-return规则文档crates/lint/docs/unused-return.md为核心结合其 Rust 实现与测试用例系统讲解该静态检查的检测范围、判定原理、修复方式与边界行为帮助 Solidity 开发者将这一规则正确接入日常合约审计与 CI 流程。unused-return是 Foundry 内置forge-lint静态分析器位于crates/lint中一条**中等严重度Med**的 Solidity 检查规则核心职责是识别高层外部调用返回了值却被整体丢弃的写法。丢弃返回值往往意味着应用层错误被静默吞掉或查询结果被无视是 DeFi 合约中一类典型隐患。读完本文你将掌握该规则的精确触发条件、源码级判定逻辑、与其姊妹规则erc20-unchecked-transfer的分工以及如何借助仓库内置测试用例理解各种边界情形。规则速览属性值规则 IDunused-return严重度Med说明文案return value of an external call is not used源码位置crates/lint/src/sol/med/unused_return.rs文档位置crates/lint/docs/unused-return.md测试用例crates/lint/testdata/UnusedReturn.sol 与 UnusedReturn.stderr在 lint 注册表中crates/lint/src/sol/med/mod.rs该规则以unused_return: (UnusedReturn, late, (UNUSED_RETURN))注册属于late pass——即在 Solar 完成语义分析、能够解析出函数类型与返回列表之后才运行的检查阶段。检测范围什么会被标记根据规则文档What it doesunused-return检测以下两类情况高层外部调用对接口、合约实例发起的外部external函数调用函数声明了返回类型但整个返回值被丢弃。外部库调用经由外部库library发起的、带有返回值的调用同样纳入检测。元组返回的缺槽当被调函数返回元组多返回值时只要任意一个槽位在解构赋值中被省略写成空位即使其余槽位被使用也会触发告警。同时文档明确了两类排除项ERC20transfer/transferFrom这两个函数虽然返回bool且常被裸调但被刻意排除在unused-return之外改由独立的高严重度规则erc20-unchecked-transfer专门负责详见后文与 erc20-unchecked-transfer 的分工。内部调用包括内部函数调用、库的内部调用以及经由基类限定qualified base-contract的内部调用均不触发本规则。为什么这是坏味道规则文档Why is this bad?给出的理由值得仔细咀嚼隐藏失败丢弃返回值会掩盖通过该返回值上报的应用层失败。很多合约并不通过 revert 报错而是以返回值如bool、状态码、价格是否有效等传递业务层面的失败信号。忽略查询结果把一次查询如预言机报价、余额、配置项的返回结果随手丢弃等于放弃了调用它的意义。文档特别澄清了一个常见误区高层外部调用即使丢弃返回值revert 依然会向上传播EVM 调用层级的失败不会被吞掉。因此本规则针对的并不是revert 被吞这一类问题而是成功返回后携带的信息被白白扔掉——这是一个语义层面的缺陷而非调用失败处理层面的缺陷。这一定位决定了它的严重度被定为Med而非High。源码级判定原理要精确理解触发条件需要读一下规则实现 unused_return.rs。其核心逻辑分为两层。第一层语句形态匹配check_stmtLateLintPass的check_stmt只对三类语句形态做进一步判断unused_return.rs#L23-L38let (call, span) match stmt.kind { StmtKind::Expr(expr) match expr.peel_parens().kind { // (x, ) call() with an ignored slot. ExprKind::Assign(lhs, None, rhs) if tuple_elems(lhs).is_some_and(|e| e.iter().any(Option::is_none)) { (rhs, expr.span) } _ (expr, expr.span), }, StmtKind::DeclMulti(vars, expr) if vars.iter().any(Option::is_none) { (expr, expr.span) } _ return, };纯表达式语句oracle.getPrice(t);这种裸调用语句整个表达式被当作语句丢弃。带缺槽的元组赋值(price, ) oracle.latest(t);左值元组中任意一个元素为None空槽。带缺槽的多变量声明(uint256 price, ) oracle.latest(t);声明列表中存在None元素。注意这里对左侧元组使用了tuple_elems(lhs)并检测Option::is_none正是元组返回有任意槽位被省略这一规则的直接落地。而不带缺槽的完整解构两个值都取不会进入该分支由后面的返回值使用分析放行。第二层调用性质判定is_unused_return_call拿到候选调用表达式后is_unused_return_call 做四步过滤必须是调用表达式需为ExprKind::Call且被调用方是成员访问ExprKind::Member即receiver.method(...)形态。必须是外部/委托调用函数类型通过gcx.type_of_expr解析出函数类型仅当TyFnKind::External或TyFnKind::DelegateCall时才继续。这是内部调用被排除的代码级依据——内部函数不属于这两种调用种类。必须能解析到函数定义gcx.resolved_function(callee)解析出函数 ID进而取得其声明f.returns。返回列表非空且非 ERC20 transfer!f.returns.is_empty() !is_erc20_transfer。换言之被调函数声明了至少一个返回值且不是被豁免的 ERC20 形态。ERC20 豁免的精确算法豁免判断unused_return.rs#L59-L68非常严谨它要求返回签名与参数签名同时匹配——transfer需为returns (bool) 参数(address, uint256)transferFrom需为returns (bool) 参数(address, address, uint256)且各参数、返回值均为基础类型is_elementary。这样既不会误伤恰好同名但签名不同的函数也保证了对标准 ERC20 形态的精确识别。触发示例与修复写法规则文档给出了标准对比例子完整如下。触发写法返回值被静默丢弃interface IOracle { function getPrice(address token) external returns (uint256); } contract Example { IOracle oracle; function updatePrice(address token) external { oracle.getPrice(token); // return value silently discarded } }推荐写法将返回值落盘或显式消费interface IOracle { function getPrice(address token) external returns (uint256); } contract Example { IOracle oracle; uint256 public lastPrice; function updatePrice(address token) external { lastPrice oracle.getPrice(token); } }修复思路与Why is this bad?一一对应把返回值赋给状态变量如lastPrice、传给require断言、或参与后续运算让成功调用的返回信息真正被使用。边界行为从测试用例看判定细节规则仓库内置了非常详尽的测试契约 UnusedReturn.sol文件头通过//compile-flags: --only-lint unused-return让测试仅启用本规则。逐条阅读可以提炼出以下边界语义~WARN注释即期望诊断与 UnusedReturn.stderr 中的 9 条告警一一对应触发应告警的场景场景代码形态说明uint256返回值被丢弃oracle.getPrice(t);最基础形态非 ERC20 的bool返回值被丢弃oracle.update();bool同样受检显式接口强转后调用IOracle(oracleAddr).getPrice(t);强转不影响判定重载函数命中有返回值版本oracleOverloaded.getPrice(t);同一名字下按签名解析只有选中版本有返回才触发命名参数调用oracle.getPrice({token: t});命名实参不影响元数判断括号包裹接收者(oracle).getPrice(t);/(IOracle(oracleAddr)).getPrice(t);peel_parens剥括号后仍判定元组解构含空槽声明式(uint256 price, ) oracle.latest(t);缺槽即告警元组解构含空槽先声明后赋值式(price, ) oracle.latest(t);同上放行不应告警的场景场景代码形态说明返回值存入局部变量uint256 price oracle.getPrice(t);捕获即视为已使用返回值直接参与表达式return oracle.getPrice(t);直接消费函数本身无返回值oracle.noReturn();returns为空不触发ERC20transfer/transferFromtoken.transfer(to, amt);移交给erc20-unchecked-transfer重载命中无返回值版本oracleOverloaded.getPrice(id);选中版本无返回元组完整解构且均被读取(uint256 price, bool ok) oracle.latest(t);无空槽捕获后分支读取if (cond) return price;只要有读取路径即视为使用注意最后两类good7–good10表明返回值捕获进变量后即使被覆盖、或仅在某个分支读取都算作已使用——该规则放行的粒度是调用结果是否被消费不做数据流层面的死代码分析避免误报。与 erc20-unchecked-transfer 的分工unused-return特意豁免 ERC20transfer/transferFrom是因为 Foundry 有更严厉的专门规则 erc20-unchecked-transfer严重度HighERC20 规范允许代币通过返回false而非 revert 来报告失败忽略bool会让失败的转账无声无息导致账目漂移并成为常见 DeFi 攻击面。两条规则的关注点差异总结如下维度unused-returnerc20-unchecked-transfer严重度MedHigh目标任意外部调用返回值的丢弃仅 ERC20transfer/transferFrom的bool未检查底层理由应用层失败/查询结果被吞ERC20 用返回值而非 revert 报告失败建议修复赋值给状态变量、参与运算require(...)断言或使用SafeERC20包装对应测试文件分别为 UnusedReturn.sol 与 UncheckedTransferERC20.sol。两者互补一个管返回值语义丢失一个管ERC20 特有失败信号被忽略。如何在项目中启用与验证unused-return随forge-lint内置提供无需额外安装插件。测试用例中使用--only-lint unused-return单独启用该规则便于在 CI 或本地对单一规则做聚焦检查正式项目中通常直接运行默认的forge lint让全部规则含本规则参与扫描即可。如需扩展验证该规则在自定义合约上的行为可以直接参考并复用仓库内的测试契约 UnusedReturn.sol——其中覆盖了重载、强转、命名参数、元组缺槽、ERC20 豁免等全部关键路径是理解规则边界最完整的活文档。小结unused-return是 Foundry lint 体系中一条语义清晰、边界精确的中等严重度规则它聚焦高层外部调用成功返回后的信息丢失通过语句形态匹配 函数类型解析两层判定实现并在源码与测试中严格划清了与erc20-unchecked-transfer的职责边界。理解其源码实现unused_return.rs与测试用例UnusedReturn.sol不仅能帮你准确修复告警也能避免过度修复——例如对 ERC20 转账的bool处理应交给高严重度的专用规则而不是在本规则下误伤。【免费下载链接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.项目地址: https://gitcode.com/GitHub_Trending/fo/foundry创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考