[JuliaLowering] Restrict K"VERSION" to module arg

[mlechu]

Fixes stdlib precompilation after #60018: the v_str macro produces a
VersionNumber, which becomes K"VERSION", which is unhandled syntax. I
think the intent was to only give it special treatment as the child of a
module expression (not make VersionNumber special syntax).

[Keno]

Yes, I did not intend a generic VersionNumber <-> K"VERSION" embedding. However, I don't think this PR works as is. First there are two places, this shows up, one is in the module, the other is in @VERSION. The second issue as inline, I don't think the runtime likes this. Can we do this conversion in the appropriate head for the :module or :macrocall heads?

[mlechu]

Instead of introducing K"VERSION" in converting the macrocall, would it make sense to just handle it in macro expansion (symmetric to your change in jl_invoke_julia_macro)?

[Keno]

That sounds reasonable, but I don't know JuliaLowering well enough to really think it through.

[mlechu]

I'll give it a shot. What is the reason for having the K"VERSION" node instead of just a K"Value" anyway? Is it a request for JuliaLowering to fill in its version info?

[Keno]

There's no place for the parser to store a VersionNumber, so it needs to be encoded into the flags. I would be fine it was a K"Value" in lowering.

[mlechu]

(update after trying it:) Using K"Value" in module would be simpler, but would require differences between SyntaxNode and SyntaxTree (I do want this, but that starts with #60162).

The macrocall should work now, though I'm not sure how to reason about it. Meta.parse("@VERSION") and Expr(JS.parse("@VERSION")) produce different answers, and in general I think we're treating the SyntaxNode->Expr conversion as an assumed post-processing step, where JuliaLowering's input doesn't necessarily go through this step.

[topolarity]

This is important to get stdlibs green again on JuliaLowering, so I'm merging this as-is, but follow-up feedback is welcome