Fix static const variable handling in opir

[gokr]

I used Claude Code to fix the "static const" problem (Futhark just generating var type declarations without values). Claude created a fair bit of code so it could read the header source and try to generate a Nim initializer based on it, can probably be done simpler - but at least you can use this PR as inspiration! And probably better to just WARN and not generate var declarations.

The rest below is from Claude.

Previously, C static const variables were incorrectly generated as Nim var declarations without values, making them unusable. This commit adds proper detection and conversion of static const variables to Nim const declarations.

Changes:

• Added getInitializerText() to extract initializer expressions from C code
• Added convertInitializerToNim() to translate C expressions to Nim format
• Modified genVarDecl() to detect static const variables (NoLinkage or Internal linkage with const-qualified type)
• Successfully converted initializers generate "kind": "const" JSON with values
• Failed conversions log clear warnings and skip generation entirely (return nil)

Supported initializer types:

• Numeric literals: integers (decimal, hex, octal, binary), floats
• String and character literals
• Type suffixes: u, l, ll, f, etc.

Unsupported (warns and skips):

• Macro function calls: orx2F(3.14f), orx2D(1.0)
• Type cast expressions: (uint32_t)(-1)
• Complex expressions requiring evaluation

Example warnings:
Warning: Cannot translate initializer for static const 'orxFLOAT_MAX': orx2F(3.402823466e+38f) - skipping Warning: Cannot translate initializer for static const 'orxU32_UNDEFINED': (orxU32)(-1) - skipping

This ensures static const variables are either properly converted with values or clearly flagged as unsupported, rather than generating broken var declarations.

🤖 Generated with Claude Code

[heysokam]

Mandatory disclaimer: I'm not a Futhark dev.

Lets please not add AI nonsense into a compiler tool.
Futhark code is hard enough to follow as it is.
This code is so overkill, only to fix something that already worked in the past.

As far as I'm aware, PMunch has been busy and hasn't been able to invest much time into futhark,
hence why the bug is still there.
But I'll let him speak for himself.

[gokr]

No need to be so hostile! :) And no, it can never have "worked in the past" (at least not for my case) since expression initializers were the culprits for my static const to end up as var type declarations. Simply because Futhark can not translate those. As I wrote, use the PR as inspiration and PMunch can fix it whichever way he likes.

One reasonable approach, as I mentioned, is to just warn and not generate anything at all. Which is exactly what my fork of Futhark now does (since my initializers are untranslatable because they use C macros).

[gokr]

To make it more clear, if I understand "static const" correctly - without it being defined as "extern" then the idea is that each program including this header would get its own copy of it. So it would need to be able to fully evaluate the expression for the value. The logic can probably be improved to cover the "extern" case but for my case where I have weird expressions using custom macros - I simply needed to reimplement those in my Nim high level wrapper. So I just wanted Futhark to not generate anything (to avoid clashes).