Add const fn

[joannabrozek]

This PR adds partial support for constexpr fn expression:

• allow parsing 'const fn'
• evaluate invocations of const functions during conversion to IR
• handle parametric functions

[rw1nkler]

FYI @richmckeever

[joannabrozek]

@richmckeever, is there anything else that should be added?

[richmckeever]

We were discussing with Robert last week that it would be good to document a proposal for what "const fn" actually means, including restrictions surrounding them, alternatives considered, etc. and review that. In some ways it is less obvious what it should mean than with const if and match, for example.

The initial thought was that something like std::clog2 would be eligible to be declared const, i.e. the function can have parameters, and the parameters may or may not be constexpr, but when they are constexpr, a function call should be reducible to a literal in the IR. There is then a question of whether we should start requiring that anything you try to invoke at compile time (e.g. from parametric default exprs) is declared const. Maybe eventually but not until the stdlib functions commonly used at compile time are updated?

The PR currently seems to be based on a narrower idea of what functions are eligible to be declared const (only no-parameter free functions maybe?) but it can probably be tweaked to match whatever the proposal says. I think allowing parameters and being in an impl would be 2 situations we would probably need to handle.

[rw1nkler]

In Rust, const fn refers to functions that are guaranteed to be evaluated at compile time. They act as a contract between library authors and users - if someone relies on a function being const fn, future implementations must preserve its ability to be evaluated at compile time. A non-const fn could be used in the same places, but without guarantees that future changes won’t break compile-time evaluation.

The question is whether such a statement is useful for DSLX right now. In other words, are there expressions that could break compile-time evaluation of a function without changing the arguments? At the moment, this does not seem to be the case. DSLX functions are pure, so if a function is called with constant-expression arguments, it is guaranteed to be evaluated at compile time. Another question is whether there are plans to change the behavior of functions in the future. If so, stronger guarantees might be desired.

Finally, there is the question of whether the current toolchain handles such constexpr evaluation well. Specifically, does calling a function with all constexpr arguments always produce a constexpr value, that can can be used in range expressions or to initialize parametrics? We have to verify this. For now, it may be more beneficial to improve other parts of the toolchain to handle constexpr better and ensure the IR optimizer correctly replaces such function calls with literal values.

[rw1nkler]

We were discussing with Robert last week that it would be good to document a proposal for what "const fn" actually means, including restrictions surrounding them, alternatives considered, etc. and review that.

I agree that we should probably hold on, and discuss in details what we want to achieve and whether this idea is/will be useful in DSLX language.

[proppy]

I agree that we should probably hold on, and discuss in details what we want to achieve and whether this idea is/will be useful in DSLX language.

making this back to draft until we're ready to discuss it again, @rw1nkler feel free to link/summarize the discussion if it already happened.