New Issue: 'const ref' declarations don't result in 'const' pointers in generated code

Notifications Issues
1

27218, "bradcray", "'const ref' declarations don't result in 'const' pointers in generated code", "2025-05-06T19:58:51Z"

In a demo today, @jabraham17 asked a question revealing that when we pass an argument by const ref intent, we create a non-const pointer in the generated C code (and I strongly suspect the same is true in the LLVM back-end as well). The same seems to be true for a standalone const ref declaration. Note that we do check that we don't take a non-const ref to a const value, so we are not permitting modifications to const things as a result of this (so far as I can determine), but are simply not providing as much semantic information to the back-end C compiler as we could be.

I determined this by looking at patterns like:

proc foo(const ref x = 0) {  // or `extern proc foo(const ref x = 0)`
  writeln("x is: ", x);
}

var x = 42;

foo(x);

const ref r = x;

writeln(r);

and finding that:

  • foo() was declared to take an int64_t* rather than a const int64_t*
  • we passed x using &x rather than (const int64_t*)&x
    • (and similarly for an extern proc where the temp we inserted had type int64_t* rather than const int64_t*
  • r is declared to have type int64_t* rather than const int64_t*