[JuliaLowering] Fix @nospecialize multi-arg and add 0-arg

[aviatesk]

Split the single @nospecialize(ctx, ex, exs...) method into properly typed variants:

• 0-arg: emits [K"meta" "nospecialize"] for blanket usage
• 1-arg: applies _apply_nospecialize to the argument
• 2+-arg: applies _apply_nospecialize to all arguments

The previous implementation only processed the first argument when multiple were given (the rest were silently ignored).

[topolarity]

This should also include tests for the added support, but otherwise LGTM

[topolarity]

Would be good to add a broken test for the body form (which doesn't work, as noted in

julia/JuliaLowering/src/desugaring.jl

Line 2582 in 3a3289a

# TODO: Ensure we preserve @nospecialize metadata in args

).

A kwargs example would also be good (and is similarly broken for the body form). Sorry to make you add so many tests, but it seems prudent when we run into loose ends like this.

[aviatesk]

Added. Regarding keyword argument methods, it hasn't been decided yet how @nospecialize should be propagated, so it might be better to decide that before writing tests.
Even if we add @nospecialize to the keyword methods themselves, we might not get the desired effect unless we also @nospecialize the NamedTuple argument that kwcall receives.

[topolarity]

To clarify, the bug applies to the positional arguments as well, which don't propagate through the helper method either.

[aviatesk]

Yeah, I added a new broken test case for that.

[topolarity]

I mean this case:

function f_body_nospecialize_default(x; y=1)
    @nospecialize x
    (x, y)
end
(f_body_nospecialize_default(10; y = 20), f_body_nospecialize_default(30))

flisp labels x as nospecialize in both the "body" and "wrapper" functions.

[aviatesk]

Ok, added that case too. Let me elaborate my thinking on this part a bit

Regarding keyword argument methods, it hasn't been decided yet how @nospecialize should be propagated, so it might be better to decide that before writing tests.

So in order to correctly nospecialize the keyword arguments, I believe we need to add nospecialize for the NamedTuple argument of the keyword sorter method as well as their corresponding arguments of the keyword body method, but we currently don't implement this. The keyword body method nospecialization would just be fine, but adding @nospecialize for the NamedTuple means we won't specialize the entire keyword arguments set of the keyword sorter method, so some caution might be needed.

[topolarity]

We'll probably have to re-work the fix for body @nospecialize soon, given the need to propagate it to derived positional / kwargs methods. @mlechu can you add this to your list of proper fixes needed?

Otherwise changes LGTM w/ a couple additional tests - definitely an improvement. Thanks @aviatesk