Skip to content

Conversation

@rw1nkler
Copy link
Contributor

@rw1nkler rw1nkler commented Oct 31, 2025

This PR adds support for the constexpr if expression.

Information about the const modifier is stored in the Conditional class and used later during type checking. For constexpr if, separate type variables are assigned to each branch of the condition. At this stage, the result is not directly bound to them. During the TypeInfo generation, the constexpr condition is evaluated, and one branch of the if is selected. Its type is unified, and the entire if is annotated with that type. The bytecode emitter and IR converter have been updated to inline the selected branch, skipping the unchosen one.

Proper tests for this feature are still needed and will be added soon.

One issue not yet handled correctly in this PR is the conditional spawning of procs, for which an example has been added that shows the problem. Currently, all spawns affect the type, which should not happen as only the selected branch of constexpr if should be considered. One possible approach is to enable constexpr evaluator in the PopulateInferenceTableVisitor and skip traversing the branch that was not taken. However, the PopulateInferenceTableVisitor does not have access to the parametric environment, and the condition relying on the parametrics seems to be the most imprtant use-case for using constexpr if when spawning procs.

@rw1nkler rw1nkler force-pushed the 80074-const-if branch 4 times, most recently from 7eaf714 to 4000a7d Compare November 20, 2025 13:22
@rw1nkler rw1nkler marked this pull request as ready for review November 20, 2025 13:40
@rw1nkler rw1nkler changed the title WIP: Add constexpr if Add constexpr if Nov 20, 2025
Copy link
Collaborator

@richmckeever richmckeever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's add tests in typecheck_module_v2_test to prove that for example it's OK to have disparate types in the branches of the const if in a function like:

fn f<N: u32>() -> uN[N] {
  const if (N == 1) {
    u1:0
  } else {
    zero!<uN[N]>();
  }
}

@wsipak wsipak force-pushed the 80074-const-if branch 2 times, most recently from 259f952 to b29930e Compare December 9, 2025 14:06
@wsipak
Copy link
Contributor

wsipak commented Dec 16, 2025

I've applied changes requested in the review.
I've included a test with the function:

fn f<N: u32>() -> uN[N] {
  const if (N == 1) {
    u1:0
  } else {
    zero!<uN[N]>()
  }
}

This previously failed due to wrong TypeInfo object being used for the conditional evaluation - this is now fixed.

I've also included an example with conditional proc spawning. In order to spawn procs in const if, a change was required in the ProcConfigIrConverter which is also present in this PR.

FYI @richmckeever

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants