Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Linker: an external's global initializer is parsed before the tier gate, producing a misleading error for position-independent builds

オープン
  • 何か問題がありますか？
#421 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
58/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
rust
領域
compilers

調査の方向性

Start by reading collect_global and compare its handling with the role-based handling of inference.spec_funcs and inference.hspecs; trace where external-module globals and tables are consumed. Reproduce with an external module whose global initializer uses global.get, then verify it reaches the import check and reports that the external module imports its environment without inspecting the initializer.

索引モデルが issue の本文から書いたものです。

説明

Problem

collect_global runs on external modules during parse — before tier classification and before the non-function-import check. It accepts only i32.const/i64.const initializers and hard-errors otherwise.

Since the global/table gate now keys on use rather than declaration, an external's globals are dropped by construction: the merged output emits the main module's globals only, and a closure that reads a global is still Tier C. So for an external, parsing the initializer expression is work whose only observable output is an error message about a global the merge never emits.

That message is actively misleading on the path users are advised toward. RequiresRelocatableBuild tells them to "build the external module with a relocatable/position-independent toolchain"; doing so produces a global.get-based (PIC) initializer, and the link then fails with:

unsupported WASM construct for static merge: unsupported global initializer for the
static merge: GlobalGet { global_index: 0 } (only i32.const/i64.const are modeled)

The near-identical shape without a global of its own reports the accurate, actionable error instead:

external module providing `sum` imports its environment

Same root cause, two different errors, and the misleading one lands on the shape the advice steers users to.

Proposal

Make collect_global role-aware, mirroring the existing role-based handling of the inference.spec_funcs / inference.hspecs custom sections: for an external module, retain nothing (or a kind-only record) and never inspect the initializer expression. The PIC case then falls through to the import check and reports "imports its environment", which is accurate.

This is strictly less code than today, and it makes "an external's globals are inert" structural rather than incidental.

Notes

  • The reachable surface is narrower than it looks: a float global is caught by the feature gate first, ref.null/ref.func initializers need reference types (excluded), and extended-const is excluded. global.get of an imported global is essentially the only reachable case — which is exactly the PIC case above.
  • Do not widen the modeled initializer set. Nothing consumes an external's global initializer.
  • After the use-vs-declaration change, an external's parsed tables has no production reader at all and its globals are write-only apart from this parse failure; worth a look while here.

Found during a review of the tier declaration-vs-use change in #363.

Refs: #363, #420.

主要言語
Rust
スター
25
フォーク
17
平均マージ
21時間 35分
マージ済み PR（30日）
34

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Inferara/inference のほかの issue

Inferara/inference の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。