[Bug]: when array element type omitted, compiler makes something up?

[cassella]

Summary of Feature

I was hoping the compiler would be able to figure out that I want a two dimensional array of ints here. A more helpful error would be an improvement also:

Code Sample

var A: [{0..10, 0..10}] = -1;

compilerWarning(A.type:string);
A[5,5] = 1;

I found the error reported to be unenlightening:

what.chpl:4: error: domain slice requires a range in at least one dimension

Which is reported on the A[5,5] line.

Based on the compilerWarning output, I think the compiler is saying the type of A is a one dimensional array of two dimensional domains?

what.chpl:3: warning: [domain(1,int(64),one)] domain(unmanaged DefaultRectangularDom(2,int(64),one))

That resembles my attempted domain-part of the declaration, like it's interpreted it as A: [{1..10,1..10}].type, but I'm not sure what it would mean to say A : an array, and it doesn't seem like you can write something like var A: [1,2,3] in general.

If I remove that A[5,5] line, the compiler reports that there was also an error on the initialization line that's more helpful, but that it hadn't shared earlier:

what.chpl:1: error: cannot initialize [domain(1,int(64),one)] domain(unmanaged DefaultRectangularDom(2,int(64),one)) from int(64)

Is this issue currently blocking your progress?
No.

[bradcray]

@cassella : Thanks for filing this!

I'd call this a bug, and suspect it may have crept in when dyno took over the front-end parsing. Specifically, this form of array declaration (omitting the element type and inferring it) used to result in a syntax error [TIO] and I don't recall that we put in the effort to support the pattern (though I think we'd like to consider doing so—that is, "let me tell you the indices I want, but you can figure out the element type for me.")

For others reading and curious: removing the {…} above doesn't seem to make a significant difference [ATO]. Switching to a 1D array gives a specialized error message that also seems to imply something is causing the compiler to interpret this as an array of ranges [ATO].

[dlongnecke-cray]

This looks like a bug to me. I expect what's going on is that we're not translating the AST right when lowering to the middle-end. Brad's right that [ ... ] = ... is a new pattern and I probably didn't put as much care into translating it as the stuff that's already tested. I'll try to see if we can support this (with at least an error message) though if it doesn't fall out it'll probably wait until we replace the frontend.

[bradcray]

I renamed the issue given David's concurring opinion.