Repository navigation
Default-initialized local static constexpr in constant evaluation [GH #399] - #417
daveedvdv-nvidia wants to merge 1 commit into
Conversation
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Interpreter handling src/interpret.c |
stmk_init skips allocation and initialization for variables with static or thread storage duration. |
GH #399 regression coverage tests/tests/changes/gh-399.sft.cpp, tests/tests/changes/.gh-399.rto/default.1.1.txt, src/pending_changes/gh-399-default-initialized-local-static-constexpr.txt |
The C++23 test checks default-initialized local static constexpr objects with a member initializer, a user-defined constructor, and a template. The fixture selects C++23 mode. The pending-changes note describes the reported issue and states it is fixed. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Bug fix · Severity of issue fixed: Medium
Suggested reviewers: nv-cmeerw
Merge Risk: 
Minimal · up to b38cc
-
No concrete merge-blocking defect was established in the changed interpreter logic or regression coverage.
Pre-merge checks: 
5
-
Full details: Title check
-
Explanation
The title names the actual change: default-initialized local static constexpr variables during constant evaluation, with the linked issue GH
#399. It matches the interpret.c change that skips stmk_init handling for static or thread storage duration variables. It is specific enough for a teammate scanning history. Minor note: the title does not say that the fix skips allocation for static and thread storage variables, but it does not need to cover every detail.
Full details: Linked Issues check
-
Explanation
Issue
#399requires C++23 constant evaluation for a default-initialized local static constexpr class object. The change skips stmk_init processing for variables with static or thread storage duration. The existing reference evaluation can then obtain the constant-initialized value. tests/tests/changes/gh-399.sft.cpp directly covers the reported Q example and adds user-constructor and template cases.
Full details: Docstring Coverage
-
Explanation
No eligible functions found in the changed files. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 0 functions across 1 files. (3 skipped: 2 unsupported, 1 too large.)
-
Finishing Touches
-
📝 Generate docstrings
-
- Commit to this branch
- Create a new PR
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Comment @coderabbitai help to get the list of available commands.
|
AcknowlEDG review results updated for
|
|
AcknowlEDG review results updated for
CI success. |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
ee2c076 to
a98c367
Compare
|
AcknowlEDG review results updated for
|
|
AcknowlEDG review results updated for
CI success. |
a98c367 to
b38ccbe
Compare
Fixes #399.
In C++23 mode, a local
static constexprvariable is permitted in a constexpr function (P2647R1), and thestmk_declcase of the statement interpreter accepts it because it is usable in constant expressions. However, a default-initialized variable of class type also gets anstmk_initstatement (for its constructor call), and the interpreter treated that like the initialization of an automatic variable: it tried to allocate interpreter storage for the static variable and to run its initializer, which failed.The
stmk_initcase now skips variables with static or thread storage duration: their value is obtained (from their constant initializer) when they are referenced, as for any other variable usable in constant expressions.Tests: new
changes/gh-399.sft.cpp.Summary by CodeRabbit
static constexprvariables of class type. These variables are now evaluated correctly in functions with default member initializers, user-defined constexpr constructors, and templates, allowing valid constant expressions in these scenarios to compile successfully.