Symbol array literals in macros

[wout]

Bug Report

Today I encountered a weird issue that was caused by a symbol array literal. When using the %i[something] format a compile-time error is raised, when using [:something] not.

More specifically, I came across the error when defining a has_many association with a through option in Avram:

has_many tags : Label, through: %i[tag_labelings label]

This raised:

 11 | has_many tags : Label, through: %i[tag_labelings label]
     ^
Called macro defined in lib/avram/src/avram/associations/has_many.cr:2:3

 2 | macro has_many(type_declaration, through = nil, foreign_key = nil, base_query_class = nil)

Which expanded to:

 > 18 | 
 > 19 |     define_has_many_lazy_loading(tags, Label, blip_id, [:tag_labelings, :label] of ::Symbol)
 > 20 |     define_has_many_base_query(Web::Blip, tags, Label, blip_id, [:tag_labelings, :label] of ::Symbol, Label::BaseQuery)
                                                                                                                              ^
Error: expecting token '->', not ')'

Using an array of symbols works as expected:

has_many tags : Label, through: [:tag_labelings, :label]

Crystal version
Crystal 1.19.0 (2026-01-14)

LLVM: 18.1.3
Default target: x86_64-pc-linux-gnu

OS
Ubuntu 24.04.3 LTS

[straight-shoota]

Could you please provide a reproducible example or a bit more context about how the macro works?

[HertzDevil]

It is a syntax error, the macro is not necessary here:

p([] of Int32, 1)      # okay
p([] of Int32, String) # Error: expecting token '->', not ')'

[wout]

https://github.com/luckyframework/avram/blob/main/src/avram/associations/has_many.cr#L46

It is a syntax error, the macro is not necessary here

Is it because the %i[tag_labelings label] literal is rendered as [:tag_labelings, :label] of ::Symbol by the macro?

[HertzDevil]

It is true that literals and AST node methods could introduce such errors silently even though the original literal forms do not cause a parsing ambiguity. #11966 suggests making the parentheses around a ProcNotation mandatory in cases like this.

[straight-shoota]

Yes, and because it's followed by a comma and a path. See the reduction in #16577 (comment)

The compiler tries to read the type as a proc type which in this case doesn't work at all because there is no ->.

Oddly, this seems to be only an issue with a typed array literal, not with a blank path. This parses just fine:

p(Int32, String)

When an actual proc type is involved, there is actual ambiguity: Int32, String -> Bool could be parsed as Int32, (String -> Bool) or (Int32, String) -> Bool. However, the compiler already handles this case (with the opposite assumption from the error in the OP):

p(Int32, String -> Bool) # SyntaxError: expecting token ')', not '->'