non-evaluator attribute requires manual propagation across entire call chain
まだ誰も着手していません。
評価
調査の方向性
Start by finding the original PR or issue that introduced the non-evaluator attribute, then survey its use outside mir-semantics, including the EXPERIMENT-no-llvm-kompile-updated branch. Trace how the Haskell backend sends call chains and requires clauses to the LLVM backend; done means identifying the root cause, choosing a solution direction, and implementing and verifying it.
索引モデルが issue の本文から書いたものです。
説明
Problem
The non-evaluator attribute marks a function so it is not evaluated by the LLVM backend. However, in practice, marking a single function as non-evaluator is not enough — every function in the call chain above it must also be manually marked, otherwise the Haskell backend will still send the caller to the LLVM backend, which then encounters a non-evaluator function it cannot handle.
Example:
syntax Int ::= A(Int) [function, non-evaluator]
syntax Int ::= B(Int) [function]
rule B(X) => A(X) +Int 1
Ais markednon-evaluatorBis not markednon-evaluator- When the Haskell backend simplifies
B(42), sinceBis notnon-evaluator, it sendsB(42)to the LLVM backend - The LLVM backend attempts to evaluate, unfolds the rule, and encounters
A(42)— butAisnon-evaluatorand the LLVM backend cannot handle it correctly - Workaround: manually add
non-evaluatortoBas well. But then all callers ofBalso need it, and so on — propagating up the entire call chain
The same issue occurs when a requires clause references a non-evaluator function.
This was discovered in the mir-semantics project (EXPERIMENT-no-llvm-kompile-updated branch), which has many functions unsuitable for LLVM backend execution.
Expected Behavior
non-evaluator should not require manual propagation. Possible directions:
- The compiler automatically analyzes the call graph and propagates the attribute
- The Haskell backend recognizes when a term contains
non-evaluatorfunctions and handles them itself - The LLVM backend gracefully returns unevaluated terms when encountering
non-evaluatorfunctions
Suggested First Steps
Before choosing a solution, some investigation is needed:
- Find the original PR/issue that introduced
non-evaluatorto understand the design intent - Survey
non-evaluatorusage in projects other than mir-semantics — do they encounter the same propagation problem? - Assess the semantics of
non-evaluatorin concrete execution (pure LLVM backend) scenarios (currently a potential concern, no observed issues yet)
Acceptance Criteria
- Research
non-evaluatorintroduction history and usage across projects - Identify root cause and solution direction
- Implement and verify
- 主要言語
- Python
- スター
- 591
- フォーク
- 163
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
runtimeverification/k のほかの issue
-
Introduce composable symbolic execution interface in pyx再び着手できるかも @Stevengre が 98 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
runtimeverification/k#4939 · 担当者 1 名 ·
-
Concolic Explorerオープン
難易度 5/5 1週間以上 初心者へのやさしさ 32/100
runtimeverification/k#4937 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
runtimeverification/k#4936 ·
-
Accelerating all-path reachability proofs with one-path reachability proofs再び着手できるかも @Stevengre が 104 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンtype:epic
runtimeverification/k#4934 · コメント 4 件 · 担当者 1 名 ·
-
Support progressive depth halving as a generic policy in `Prover.advance_proof`再び着手できるかも @Stevengre が 123 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
runtimeverification/k#4924 · 担当者 1 名 ·
runtimeverification/k の issue をすべて見る
似ている issue
-
namespace operations
難易度 1/5 1時間未満 初心者へのやさしさ 82/100
EclipseFdn/open-vsx.org#13573 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
collective/icalendar#1854 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
rancher/rancher-ai-agent#412 ·
メンテナーはふだん 6 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 84/100
TUDelftGeodesy/DePSI#134 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
HenriquesLab/rxiv-maker#335 ·