Confusing error message for a syntax error(?) in distributed domain initialization

[e-kayrakli]

Consider the following illegal code:

use BlockDist;

const Space = {1..10};

const Dom = [Space] dmapped new blockDist(Space);

writeln(Dom);

Here, in Dom's initialization, I used [Space] by mistake instead of just Space. The error message is unhelpful:

ChapelIteratorSupport.chpl:184: error: for/forall/promoted expressions are not implemented when the elements are or contain non-DefaultRectangular domains or arrays

I am not sure how parser parsed that line, but this could be a syntax error as I can't come up with something with [] legally appearing right before dmapped.

[bradcray]

I am not sure how parser parsed that line, but this could be a syntax error as I can't come up with something with [] legally appearing right before dmapped.

It's not surprising to me that it parsed w.r.t. dmapped's LHS, as the production for dmapped is simply expr TDMAPPED expr so that dmapped can be applied to a literal, variable, field access, procedure call (returning a domain), etc. without getting too specific.

The part that's unclear to me me is that I'd expect the parser to treat this as a square-bracket loop expression (as the error suggests it did), and for the production for the square bracket expression to be something like TLSBR whatever TRSBR expr (i.e., a bracket_loop_expr_base)—yet dmapped new… shouldn't be a legal expression. So I'm not sure what path the statement is taking through the parser to be interpreted as a loop expression…

[e-kayrakli]

I forget that we support [1] without a dangling comma as an array literal (was that something I fought against? :D). I was thinking that [Space] couldn't be an expression, but it could be an array literal.

[bradcray]

Aha, that's what I was overlooking as well… I wonder how much less parsing pain for square brackets we'd have if we removed that case…

[mppf]

Perhaps we should add a post-parse-check for this case rather than trying to make it a syntax error.