：狀態(tài)變量初始化器中 struct / array / bytes 成員訪問導(dǎo)致的 panic)
Foundry forge lint 修復(fù)狀態(tài)變量初始化器中 struct / array / bytes 成員訪問導(dǎo)致的 panic【免費(fèi)下載鏈接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/fo/foundry導(dǎo)讀本文聚焦 Foundry 中forge lint靜態(tài)檢查工具的一處關(guān)鍵缺陷修復(fù)當(dāng) Solidity 狀態(tài)變量的初始化表達(dá)式包含對 struct、array 或 bytes 類型的**成員訪問member access**時舊版本會在 lint 階段直接 panic 崩潰。文章將帶你理解該 bug 的觸發(fā)條件與底層根因、官方回歸測試如何驗(yàn)證修復(fù)并完整講解與之相關(guān)的function-init-state規(guī)則幫助你避免寫出存在初始化順序隱患的狀態(tài)變量聲明。變更背景一份 changelog 片段揭示的崩潰本倉庫.changelog/目錄下以 Markdown 片段形式記錄每個 PR 的版本影響與發(fā)布說明其中 lint-init-member-data-location.md 記錄了如下修復(fù)--- forge-lint: patch --- Fixed a panic when linting a member access on a struct, array or bytes inside a state variable initializer.關(guān)鍵信息有三點(diǎn)影響面forge-lint包bump 級別為patch純?nèi)毕菪迯?fù)無 API 變化崩潰場景在狀態(tài)變量初始化器state variable initializer即聲明時直接賦值的表達(dá)式中 lint 一個成員訪問表達(dá)式涉及類型成員訪問的基礎(chǔ)類型為struct、array或bytes三種引用類型時觸發(fā) panic。這個片段本身只有一行描述但它是理解這次修復(fù)的入口。修復(fù)的完整驗(yàn)證證據(jù)在倉庫的測試夾具中下文逐一展開。崩潰現(xiàn)場什么樣的代碼會觸發(fā) panic要復(fù)現(xiàn)該 bug需要先了解它所屬的 lint 規(guī)則。Foundry 的 lint 體系以 ID 嚴(yán)重級別 組織其中有一條規(guī)則叫function-init-state嚴(yán)重級別Info完整文檔見 crates/lint/docs/function-init-state.md。該規(guī)則專門檢查狀態(tài)變量初始化器如果初始化表達(dá)式引用了另一個非常量狀態(tài)變量或調(diào)用了非pure函數(shù)就發(fā)出告警。規(guī)則文檔解釋了告警的合理性狀態(tài)變量初始化器在構(gòu)造constructor階段、且先于構(gòu)造函數(shù)體執(zhí)行順序?yàn)榛惖脚缮恇ase-to-derived。因此如果某個初始化器讀取了另一個狀態(tài)變量或調(diào)用一個可能讀取狀態(tài)的函數(shù)它觀察到的可能是部分初始化的默認(rèn)值結(jié)果幾乎必然不是開發(fā)者想要的。在該規(guī)則的基礎(chǔ)上觸發(fā) panic 的代碼形如// SPDX-License-Identifier: MIT pragma solidity ^0.8.18; struct Config { address owner; uint8 decimals; } contract PanicsBeforeFix { Config internal config; uint256[] internal ids; bytes internal payload; // 以下三條初始化器在修復(fù)前都會讓 forge lint 直接崩潰 address public owner config.owner; // struct 成員訪問 uint256 public idCount ids.length; // array 成員訪問.length uint256 public payloadSize payload.length; // bytes 成員訪問.length }在修復(fù)前運(yùn)行forge lint處理上述合約會 panic修復(fù)后則能正常輸出告警這三行確實(shí)都依賴非常量狀態(tài)變量屬于規(guī)則應(yīng)報(bào)告的范圍。根因剖析data location 被剝離后members_of無法解析為什么偏偏是 struct / array / bytes 三種引用類型會觸發(fā)崩潰倉庫測試夾具中的注釋給出了直接答案。FunctionInitState.sol 末尾專門添加的InitFromReferenceType合約即本次修復(fù)的回歸測試注釋原文為Member access on a reference type inside an initializer used to abort the linter, because the base type reachedmembers_ofwith its data location peeled off. Reading a state variable is still reported, and a pure library call is still fine.即初始化器中的引用類型成員訪問曾使 linter 中止因?yàn)榛A(chǔ)類型到達(dá)members_of時其 data location數(shù)據(jù)位置已被剝離。members_of是 solar 語義分析層Gcx提供的成員解析接口它要求引用類型必須帶有 data location 包裝才能正確解析成員。這一點(diǎn)在另一個 lint 規(guī)則的實(shí)現(xiàn)中有清晰的佐證——incorrect_using_for.rs 在檢查using ... for指令時為了調(diào)用gcx.members_of會顯式把基礎(chǔ)類型分別包裝成Storage、Memory、Calldata三種 location 逐一探測// members_of expects reference types wrapped in their data location. let base_ty gcx.type_of_hir_ty(hir_ty); let tys [DataLocation::Storage, DataLocation::Memory, DataLocation::Calldata] .map(|loc| base_ty.with_loc_if_ref(gcx, loc));而當(dāng) lint 遍歷初始化器表達(dá)式、遇到config.owner這類成員訪問時基礎(chǔ)類型config是一個 state 變量其類型是 struct/array/bytes 引用類型若在進(jìn)入members_of之前該類型的 data location 被剝離peeled offmembers_of就會因缺少 location 信息而 panic。從修復(fù)后的實(shí)現(xiàn)來看function-init-state的遍歷邏輯本身并不直接調(diào)用members_of——function_init_state.rs 中的ImpureRefFinder通過resolved_variable/resolved_function判斷表達(dá)式解析到的實(shí)體再判斷是否非常量狀態(tài)變量或是否非 pure 函數(shù)可以推斷修復(fù)發(fā)生在更底層的成員解析路徑上確保members_of拿到帶 data location 的完整引用類型后不再崩潰。修復(fù)驗(yàn)證回歸測試中的三種場景回歸測試 FunctionInitState.sol 用InitFromReferenceType合約覆蓋了三種崩潰場景與一個不應(yīng)告警的對照場景contract InitFromReferenceType { Config internal config; uint256[] internal ids; bytes internal payload; address public owner config.owner; // struct 成員訪問 → 應(yīng)報(bào)告 uint256 public idCount ids.length; // array 成員訪問 → 應(yīng)報(bào)告 uint256 public payloadSize payload.length; // bytes 成員訪問 → 應(yīng)報(bào)告 uint8 public defaultDecimals Defaults.config().decimals; // 純庫調(diào)用取成員 → 不報(bào)告 }對應(yīng)期望輸出記錄在 FunctionInitState.stderr 中驗(yàn)證要點(diǎn)config.owner、ids.length、payload.length三個初始化器正常產(chǎn)生note[function-init-state]告警而不是 panic因?yàn)樗鼈冏x取了非常量狀態(tài)變量Defaults.config().decimals不產(chǎn)生告警——Defaults.config()是pure庫函數(shù)返回Config memory后取.decimals不讀取任何狀態(tài)屬于規(guī)則明確排除的合法寫法對照 Defaults 庫 的定義其函數(shù)為internal pure。這個對照場景很關(guān)鍵它證明修復(fù)不是粗暴地跳過所有成員訪問而是讓成員訪問的解析恢復(fù)正常語義判斷依然精確——純函數(shù)調(diào)用鏈上的成員讀取不會被誤報(bào)。深入function-init-state規(guī)則的完整判定邏輯理解了 panic 場景后值得把function-init-state規(guī)則的完整判定邏輯梳理一遍方便你對照排查自己的合約。function_init_state.rs 的實(shí)現(xiàn)要點(diǎn)如下1. 入口遍歷check_nested_contract對合約內(nèi)每個 item僅當(dāng)它是非常量狀態(tài)變量且?guī)С跏蓟鲿r才對其初始化表達(dá)式做深度遍歷。2. 表達(dá)式判定visit_expr對每個子表達(dá)式優(yōu)先看它是否解析為變量resolved_variable或函數(shù)resolved_function再分別判定隨后繼續(xù)walk_expr遞歸下沉到嵌套子表達(dá)式含函數(shù)調(diào)用的實(shí)參、外部調(diào)用的{gas: ...}選項(xiàng)、new創(chuàng)建的{salt: ...}選項(xiàng)等。3. 變量判定judge_variable解析到的是非常量狀態(tài)變量即告警——它的初始化器可能還沒運(yùn)行讀到的是默認(rèn)值。4. 函數(shù)判定judge_function解析到函數(shù)時若它是某個變量的合成 getterfunction.gettee則退化為對該變量的判定因此public constant的 getter 依舊安全否則只要函數(shù)的state_mutability ! Pure即告警。該規(guī)則的豐富測試用例同一文件中的InitFromFunction合約還覆蓋了大量邊界情形繼承的 view 函數(shù)調(diào)用、外部合約 getter、using for綁定的庫函數(shù)、同名重載中按實(shí)際派發(fā)選擇 pure/view 版本、super調(diào)用繞過本地 pure override、經(jīng)函數(shù)指針間接調(diào)用、immutable變量初始化器等。官方 stderr 中 18 處~NOTE: state variable initializer標(biāo)記即對這些場景的逐一斷言。實(shí)戰(zhàn)建議如何排查與修復(fù)這類問題1. 升級并復(fù)現(xiàn)。使用包含本次修復(fù)的forge-lint版本patch級修復(fù)會隨下一個forge發(fā)布進(jìn)入正式版對上述InitFromReferenceType形式的代碼重新運(yùn)行forge lint如果之前 panic 的代碼現(xiàn)在輸出note[function-init-state]告警說明修復(fù)已生效。只對單條規(guī)則做定向檢查可配合 lint 配置或--only-lint類參數(shù)測試夾具即通過//compile-flags: --only-lint function-init-state隔離該規(guī)則見 FunctionInitState.sol。2. 理解告警背后的初始化順序語義。告警并不代表代碼一定錯誤而是提醒初始化器在構(gòu)造階段按基類到派生類順序執(zhí)行、且早于構(gòu)造函數(shù)體。若你的初始化器依賴另一個狀態(tài)變量或非 pure 函數(shù)結(jié)果可能依賴執(zhí)行順序而具有隱蔽的不確定性。3. 推薦修復(fù)方式。規(guī)則文檔 function-init-state.md 給出的標(biāo)準(zhǔn)做法是把依賴狀態(tài)的初始化移到構(gòu)造函數(shù)體內(nèi)顯式賦值例如將contract C { uint256 internal seed 77; uint256 public value compute(); // 構(gòu)造函數(shù)體之前就執(zhí)行 }改為contract C { uint256 internal seed 77; uint256 public value; constructor() { value compute(); // 順序顯式可控 } }4. 引用類型的成員讀取同樣適用。本次修復(fù)的意義在于修復(fù)前config.owner、ids.length、payload.length這類引用類型成員訪問會直接讓 lint 崩潰開發(fā)者連告警都看不到修復(fù)后規(guī)則能像對待普通狀態(tài)變量讀取一樣精準(zhǔn)報(bào)告。因此遇到這類初始化器應(yīng)同樣按上述方式處理。小結(jié)本次forge-lint的patch修復(fù)解決了一個具體的崩潰缺陷狀態(tài)變量初始化器中對 struct、array、bytes 的成員訪問因引用類型的 data location 在進(jìn)入members_of前被剝離而觸發(fā) panic。修復(fù)后function-init-state規(guī)則不僅能穩(wěn)定輸出告警還能精確區(qū)分讀取狀態(tài)應(yīng)告警與純庫函數(shù)取成員應(yīng)放行。如果你在項(xiàng)目中大量使用帶初始化器的狀態(tài)變量建議升級后重新運(yùn)行forge lint并結(jié)合上述排查思路消除潛在的初始化順序隱患。參考源碼索引變更記錄.changelog/lint-init-member-data-location.md規(guī)則文檔crates/lint/docs/function-init-state.md規(guī)則實(shí)現(xiàn)crates/lint/src/sol/info/function_init_state.rs回歸測試含修復(fù)說明注釋crates/lint/testdata/FunctionInitState.sol期望輸出crates/lint/testdata/FunctionInitState.stderrmembers_of對 data location 的要求佐證crates/lint/src/sol/info/incorrect_using_for.rs【免費(fèi)下載鏈接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/fo/foundry創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Foundry forge lint 修復(fù)：狀態(tài)變量初始化器中 struct / array / bytes 成員訪問導(dǎo)致的 panic
Foundry forge lint 修復(fù)狀態(tài)變量初始化器中 struct / array / bytes 成員訪問導(dǎo)致的 panic【免費(fèi)下載鏈接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/fo/foundry導(dǎo)讀本文聚焦 Foundry 中forge lint靜態(tài)檢查工具的一處關(guān)鍵缺陷修復(fù)當(dāng) Solidity 狀態(tài)變量的初始化表達(dá)式包含對 struct、array 或 bytes 類型的**成員訪問member access**時舊版本會在 lint 階段直接 panic 崩潰。文章將帶你理解該 bug 的觸發(fā)條件與底層根因、官方回歸測試如何驗(yàn)證修復(fù)并完整講解與之相關(guān)的function-init-state規(guī)則幫助你避免寫出存在初始化順序隱患的狀態(tài)變量聲明。變更背景一份 changelog 片段揭示的崩潰本倉庫.changelog/目錄下以 Markdown 片段形式記錄每個 PR 的版本影響與發(fā)布說明其中 lint-init-member-data-location.md 記錄了如下修復(fù)--- forge-lint: patch --- Fixed a panic when linting a member access on a struct, array or bytes inside a state variable initializer.關(guān)鍵信息有三點(diǎn)影響面forge-lint包bump 級別為patch純?nèi)毕菪迯?fù)無 API 變化崩潰場景在狀態(tài)變量初始化器state variable initializer即聲明時直接賦值的表達(dá)式中 lint 一個成員訪問表達(dá)式涉及類型成員訪問的基礎(chǔ)類型為struct、array或bytes三種引用類型時觸發(fā) panic。這個片段本身只有一行描述但它是理解這次修復(fù)的入口。修復(fù)的完整驗(yàn)證證據(jù)在倉庫的測試夾具中下文逐一展開。崩潰現(xiàn)場什么樣的代碼會觸發(fā) panic要復(fù)現(xiàn)該 bug需要先了解它所屬的 lint 規(guī)則。Foundry 的 lint 體系以 ID 嚴(yán)重級別 組織其中有一條規(guī)則叫function-init-state嚴(yán)重級別Info完整文檔見 crates/lint/docs/function-init-state.md。該規(guī)則專門檢查狀態(tài)變量初始化器如果初始化表達(dá)式引用了另一個非常量狀態(tài)變量或調(diào)用了非pure函數(shù)就發(fā)出告警。規(guī)則文檔解釋了告警的合理性狀態(tài)變量初始化器在構(gòu)造constructor階段、且先于構(gòu)造函數(shù)體執(zhí)行順序?yàn)榛惖脚缮恇ase-to-derived。因此如果某個初始化器讀取了另一個狀態(tài)變量或調(diào)用一個可能讀取狀態(tài)的函數(shù)它觀察到的可能是部分初始化的默認(rèn)值結(jié)果幾乎必然不是開發(fā)者想要的。在該規(guī)則的基礎(chǔ)上觸發(fā) panic 的代碼形如// SPDX-License-Identifier: MIT pragma solidity ^0.8.18; struct Config { address owner; uint8 decimals; } contract PanicsBeforeFix { Config internal config; uint256[] internal ids; bytes internal payload; // 以下三條初始化器在修復(fù)前都會讓 forge lint 直接崩潰 address public owner config.owner; // struct 成員訪問 uint256 public idCount ids.length; // array 成員訪問.length uint256 public payloadSize payload.length; // bytes 成員訪問.length }在修復(fù)前運(yùn)行forge lint處理上述合約會 panic修復(fù)后則能正常輸出告警這三行確實(shí)都依賴非常量狀態(tài)變量屬于規(guī)則應(yīng)報(bào)告的范圍。根因剖析data location 被剝離后members_of無法解析為什么偏偏是 struct / array / bytes 三種引用類型會觸發(fā)崩潰倉庫測試夾具中的注釋給出了直接答案。FunctionInitState.sol 末尾專門添加的InitFromReferenceType合約即本次修復(fù)的回歸測試注釋原文為Member access on a reference type inside an initializer used to abort the linter, because the base type reachedmembers_ofwith its data location peeled off. Reading a state variable is still reported, and a pure library call is still fine.即初始化器中的引用類型成員訪問曾使 linter 中止因?yàn)榛A(chǔ)類型到達(dá)members_of時其 data location數(shù)據(jù)位置已被剝離。members_of是 solar 語義分析層Gcx提供的成員解析接口它要求引用類型必須帶有 data location 包裝才能正確解析成員。這一點(diǎn)在另一個 lint 規(guī)則的實(shí)現(xiàn)中有清晰的佐證——incorrect_using_for.rs 在檢查using ... for指令時為了調(diào)用gcx.members_of會顯式把基礎(chǔ)類型分別包裝成Storage、Memory、Calldata三種 location 逐一探測// members_of expects reference types wrapped in their data location. let base_ty gcx.type_of_hir_ty(hir_ty); let tys [DataLocation::Storage, DataLocation::Memory, DataLocation::Calldata] .map(|loc| base_ty.with_loc_if_ref(gcx, loc));而當(dāng) lint 遍歷初始化器表達(dá)式、遇到config.owner這類成員訪問時基礎(chǔ)類型config是一個 state 變量其類型是 struct/array/bytes 引用類型若在進(jìn)入members_of之前該類型的 data location 被剝離peeled offmembers_of就會因缺少 location 信息而 panic。從修復(fù)后的實(shí)現(xiàn)來看function-init-state的遍歷邏輯本身并不直接調(diào)用members_of——function_init_state.rs 中的ImpureRefFinder通過resolved_variable/resolved_function判斷表達(dá)式解析到的實(shí)體再判斷是否非常量狀態(tài)變量或是否非 pure 函數(shù)可以推斷修復(fù)發(fā)生在更底層的成員解析路徑上確保members_of拿到帶 data location 的完整引用類型后不再崩潰。修復(fù)驗(yàn)證回歸測試中的三種場景回歸測試 FunctionInitState.sol 用InitFromReferenceType合約覆蓋了三種崩潰場景與一個不應(yīng)告警的對照場景contract InitFromReferenceType { Config internal config; uint256[] internal ids; bytes internal payload; address public owner config.owner; // struct 成員訪問 → 應(yīng)報(bào)告 uint256 public idCount ids.length; // array 成員訪問 → 應(yīng)報(bào)告 uint256 public payloadSize payload.length; // bytes 成員訪問 → 應(yīng)報(bào)告 uint8 public defaultDecimals Defaults.config().decimals; // 純庫調(diào)用取成員 → 不報(bào)告 }對應(yīng)期望輸出記錄在 FunctionInitState.stderr 中驗(yàn)證要點(diǎn)config.owner、ids.length、payload.length三個初始化器正常產(chǎn)生note[function-init-state]告警而不是 panic因?yàn)樗鼈冏x取了非常量狀態(tài)變量Defaults.config().decimals不產(chǎn)生告警——Defaults.config()是pure庫函數(shù)返回Config memory后取.decimals不讀取任何狀態(tài)屬于規(guī)則明確排除的合法寫法對照 Defaults 庫 的定義其函數(shù)為internal pure。這個對照場景很關(guān)鍵它證明修復(fù)不是粗暴地跳過所有成員訪問而是讓成員訪問的解析恢復(fù)正常語義判斷依然精確——純函數(shù)調(diào)用鏈上的成員讀取不會被誤報(bào)。深入function-init-state規(guī)則的完整判定邏輯理解了 panic 場景后值得把function-init-state規(guī)則的完整判定邏輯梳理一遍方便你對照排查自己的合約。function_init_state.rs 的實(shí)現(xiàn)要點(diǎn)如下1. 入口遍歷check_nested_contract對合約內(nèi)每個 item僅當(dāng)它是非常量狀態(tài)變量且?guī)С跏蓟鲿r才對其初始化表達(dá)式做深度遍歷。2. 表達(dá)式判定visit_expr對每個子表達(dá)式優(yōu)先看它是否解析為變量resolved_variable或函數(shù)resolved_function再分別判定隨后繼續(xù)walk_expr遞歸下沉到嵌套子表達(dá)式含函數(shù)調(diào)用的實(shí)參、外部調(diào)用的{gas: ...}選項(xiàng)、new創(chuàng)建的{salt: ...}選項(xiàng)等。3. 變量判定judge_variable解析到的是非常量狀態(tài)變量即告警——它的初始化器可能還沒運(yùn)行讀到的是默認(rèn)值。4. 函數(shù)判定judge_function解析到函數(shù)時若它是某個變量的合成 getterfunction.gettee則退化為對該變量的判定因此public constant的 getter 依舊安全否則只要函數(shù)的state_mutability ! Pure即告警。該規(guī)則的豐富測試用例同一文件中的InitFromFunction合約還覆蓋了大量邊界情形繼承的 view 函數(shù)調(diào)用、外部合約 getter、using for綁定的庫函數(shù)、同名重載中按實(shí)際派發(fā)選擇 pure/view 版本、super調(diào)用繞過本地 pure override、經(jīng)函數(shù)指針間接調(diào)用、immutable變量初始化器等。官方 stderr 中 18 處~NOTE: state variable initializer標(biāo)記即對這些場景的逐一斷言。實(shí)戰(zhàn)建議如何排查與修復(fù)這類問題1. 升級并復(fù)現(xiàn)。使用包含本次修復(fù)的forge-lint版本patch級修復(fù)會隨下一個forge發(fā)布進(jìn)入正式版對上述InitFromReferenceType形式的代碼重新運(yùn)行forge lint如果之前 panic 的代碼現(xiàn)在輸出note[function-init-state]告警說明修復(fù)已生效。只對單條規(guī)則做定向檢查可配合 lint 配置或--only-lint類參數(shù)測試夾具即通過//compile-flags: --only-lint function-init-state隔離該規(guī)則見 FunctionInitState.sol。2. 理解告警背后的初始化順序語義。告警并不代表代碼一定錯誤而是提醒初始化器在構(gòu)造階段按基類到派生類順序執(zhí)行、且早于構(gòu)造函數(shù)體。若你的初始化器依賴另一個狀態(tài)變量或非 pure 函數(shù)結(jié)果可能依賴執(zhí)行順序而具有隱蔽的不確定性。3. 推薦修復(fù)方式。規(guī)則文檔 function-init-state.md 給出的標(biāo)準(zhǔn)做法是把依賴狀態(tài)的初始化移到構(gòu)造函數(shù)體內(nèi)顯式賦值例如將contract C { uint256 internal seed 77; uint256 public value compute(); // 構(gòu)造函數(shù)體之前就執(zhí)行 }改為contract C { uint256 internal seed 77; uint256 public value; constructor() { value compute(); // 順序顯式可控 } }4. 引用類型的成員讀取同樣適用。本次修復(fù)的意義在于修復(fù)前config.owner、ids.length、payload.length這類引用類型成員訪問會直接讓 lint 崩潰開發(fā)者連告警都看不到修復(fù)后規(guī)則能像對待普通狀態(tài)變量讀取一樣精準(zhǔn)報(bào)告。因此遇到這類初始化器應(yīng)同樣按上述方式處理。小結(jié)本次forge-lint的patch修復(fù)解決了一個具體的崩潰缺陷狀態(tài)變量初始化器中對 struct、array、bytes 的成員訪問因引用類型的 data location 在進(jìn)入members_of前被剝離而觸發(fā) panic。修復(fù)后function-init-state規(guī)則不僅能穩(wěn)定輸出告警還能精確區(qū)分讀取狀態(tài)應(yīng)告警與純庫函數(shù)取成員應(yīng)放行。如果你在項(xiàng)目中大量使用帶初始化器的狀態(tài)變量建議升級后重新運(yùn)行forge lint并結(jié)合上述排查思路消除潛在的初始化順序隱患。參考源碼索引變更記錄.changelog/lint-init-member-data-location.md規(guī)則文檔crates/lint/docs/function-init-state.md規(guī)則實(shí)現(xiàn)crates/lint/src/sol/info/function_init_state.rs回歸測試含修復(fù)說明注釋crates/lint/testdata/FunctionInitState.sol期望輸出crates/lint/testdata/FunctionInitState.stderrmembers_of對 data location 的要求佐證crates/lint/src/sol/info/incorrect_using_for.rs【免費(fèi)下載鏈接】foundryFoundry is a blazing fast, portable and modular toolkit for Ethereum application development written in Rust.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/fo/foundry創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考