You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Empty enclosing packs in generic lambdas [GH #500] - #528
A pack expansion in a generic lambda nested in a template instantiation could
produce an error node in the IL when it referenced a lambda parameter pack
before an empty enclosing parameter pack. Empty enclosing packs are now
handled correctly regardless of the order of the pack references. Spurious
warnings from prototype instantiations in such cases are also suppressed. For
example, with --c++20 -tused:
template<int... Is> voidf() {
[]<int... Js>() { ((Js * Is) * ... * 1); };
}
template void f<>(); // Previously produced an error node in the IL.
Summary by CodeRabbit
Bug Fixes
Corrected C++20 pack expansion handling in generic lambdas when an enclosing parameter pack is empty, including when pack references appear in different orders.
Suppressed spurious warnings during prototype instantiations while preserving relevant warnings during real instantiations.
No actionable comments were generated in the recent review.
Walkthrough
The compiler now sets generic-lambda pack expansion length to zero when the current pack is empty in a real instantiation. It also suppresses a warning in the related instantiation case. Regression tests cover pack combinations, warning output, and updated diagnostics.
Changes: Empty pack handling
Layer / File(s)
Summary
Expansion length and warning handling src/scope_stk.c, src/scope_stk.h, src/expr.c
The compiler sets expansion length to zero when the current pack is empty in a generic-lambda real instantiation. It exposes the instantiation check and uses it to suppress a warning in the specified case.
Regression tests cover empty and nonempty pack combinations and warning output. Imported Clang expected output removes two errors in each updated result. Imported GNU expected output updates instantiation traces. The pending-changes note describes the GH #500 case.
edgcpp/compiler#492: Suppresses missing-parameter-pack diagnostics for nested generic-lambda pack expansions and updates expected output for overlapping pack-expansion cases.
Suggested labels:bug
Suggested reviewers:daveedvdv-nvidia
Merge Risk: Minimal · up to c5dc4
The change fixes an error node in the IL for generic lambda pack expansions that reference an empty enclosing pack, and it adds regression tests. No concrete merge-blocking risk was identified.
Pre-merge checks: 4
Check name
Status
Explanation
Description Check
Check skipped - CodeRabbit’s high-level summary is enabled.
Title check
The title "Empty enclosing packs in generic lambdas [GH #500]" matches the main change. The raw summary and objectives describe a fix for an error node in the IL when a generic lambda's pack expansion…
Linked Issues check
Requirement [#500]: a pack expansion in a generic lambda nested in a real instantiation must not produce an enk_error node or tk_error type when an empty enclosing pack is referenced before a lambda p…
Out of Scope Changes check
Changes map to #500: the src/scope_stk.c fix (empty-pack handling in hybrid pack expansion), the linkage change that exposes in_generic_lambda_in_real_instantiation() and its src/scope_stk.h declarati…
Full details: Title check
Explanation
The title "Empty enclosing packs in generic lambdas [GH #500]" matches the main change. The raw summary and objectives describe a fix for an error node in the IL when a generic lambda's pack expansion references an empty enclosing parameter pack, and the title names that same subject. It is specific and concise, and it names the linked issue. No search was needed for this check.
Full details: Linked Issues check
Explanation
Requirement [#500]: a pack expansion in a generic lambda nested in a real instantiation must not produce an enk_error node or tk_error type when an empty enclosing pack is referenced before a lambda pack. The whole-PR diff of src/scope_stk.c (merge base to head) adds, in the hybrid-expansion branch, a rule that sets elements = 0 when elements_for_pack == 0. This applies regardless of which pack is encountered first, which matches the reproducer ((Seq * Vals) * ... * 1 with Vals = <>). The whole-PR diff of src/expr.c adds a suppression of the 'expression has no effect' warning when in_generic_lambda_in_real_instantiation() is true. Regression tests under tests/tests/regressions/ (gh-500.sft.cpp, gh-500.rto, gh-500-warnings.sft.cpp) cover the empty-pack case. The incremental diff from the previous reviewed head (cfe283b) to the current head (c5dc46e) could not be read, so changes made in that increment are not verified. The whole-PR diffs of the two source files match the previous assessment. Limits: I did not read the .rto expected-output files directly; the result relies on the summary for them.
Full details: Out of Scope Changes check
Explanation
Changes map to #500: the src/scope_stk.c fix (empty-pack handling in hybrid pack expansion), the linkage change that exposes in_generic_lambda_in_real_instantiation() and its src/scope_stk.h declaration (needed by src/expr.c), the src/expr.c warning suppression for generic lambdas in real instantiations (same code path as the reproducer), the pending-changes note for #500, and the gh-500 regression tests. The imported clang .lambda-pack-expansion.rto expectations drop two GH112352::S::foldExpr2 template-template-parameter errors. These are expected-output side effects of the same pack-expansion code path, not a demonstrated unrelated change. A reviewer should still confirm that removing these diagnostics is correct and does not hide a real error. The incremental diff since the previous reviewed head could not be read, so its content is not verified. No change is shown to be unrelated to #500.
Finishing Touches
Generate unit tests (beta)
Commit to this branch
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Included review availability: This review used your included allowance. Your plan provides up to 4 included reviews per hour; 3 remain after this review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #500
A pack expansion in a generic lambda nested in a template instantiation could
produce an error node in the IL when it referenced a lambda parameter pack
before an empty enclosing parameter pack. Empty enclosing packs are now
handled correctly regardless of the order of the pack references. Spurious
warnings from prototype instantiations in such cases are also suppressed. For
example, with
--c++20 -tused:Summary by CodeRabbit