The following code worked in DMD 1.045, but not with 1.056 and i think it should: uint[][] b = [[ 1, 2, ]]; The following code always works, which is odd: uint[] a = [ 1, 2, ]; I assume it is a minor parser bug. Workaround: Omit the last comma. Here is the full code i used: module main; int main(char[][] args) { uint[][] b = [[ 1, 2, ]]; return 0; } And the output of "dmd main.d": main.d(3): expression expected, not ']' main.d(3): comma expected separating array initializers, not ; main.d(4): semicolon expected, not 'return'
I think this is a duplicate of bug 3716.
(In reply to comment #1) > I think this is a duplicate of bug 3716. It was named D2 only and does not mention problems with trailing commas, thus i made it a seperate bug. I tested the code of #3716 with dmd 1.056 and it worked, so i suppose it really is a different bug.
(In reply to comment #2) > (In reply to comment #1) > > I think this is a duplicate of bug 3716. > > It was named D2 only and does not mention problems with trailing commas, thus i > made it a seperate bug. > I tested the code of #3716 with dmd 1.056 and it worked, so i suppose it really > is a different bug. The trailing commas are deliberate and part of the spec. If you want to complain about trailing commas, complain that array initializers allow them and array literal expressions don't.
Paradoxically, the absent of a trailing comma can trigger this error too. int[][][] a = [[ [1,2],[3,4], ]]; // Error Whereas: int[][][] a = [[ [1,2],[3,4], ],]; // OK Seems like a bug to me, and the patch in bug 3716 resolves this.
Created attachment 597 [details] keep track of static array initiliasiser depth OK, just for clarification. uint[][] b = [[ 1, 2 ]]; // OK uint[][] b = [[ 1, 2 ],]; // OK uint[][] b = [[ 1, 2, ],]; // OK uint[][] b = [[ 1, 2, ]]; // Error Why this happens? The scan ahead loop in parse.c isn't aware of just how deep it has navigated into the array it is scanning. First loop, scans the string: "[[ 1, 2, ]]" Second loop, because of the trailing comma, starts another parseInitializer() call, but this time scanning the string: "[ 1, 2, ]]" Because it reaches end of the scan ahead loop earlier this time, and checking the next token fails, then treats it as an expression, not an array initializer. Attached is a patch that resolves the issue. Am not sure that the patch in the other bug report is reasonably correct, but hey ho! Regards Iain
(In reply to comment #5) > > Attached is a patch that resolves the issue. Am not sure that the patch in the > other bug report is reasonably correct, but hey ho! > > Regards > Iain Eh? What makes you think it isn't?
(In reply to comment #6) > (In reply to comment #5) > > > > Attached is a patch that resolves the issue. Am not sure that the patch in the > > other bug report is reasonably correct, but hey ho! > > > > Regards > > Iain > > Eh? What makes you think it isn't? Well, from what I can tell, if I were to have the following code excerpt: int[] a = [1]]; The scan ahead routine will swallow the "[1]", and since (--brackets == 0), takes a peek at the last bracket, to which it matches in the if statement and says 'yep, that is OK'. In other words, it assumes that whether or not the above line is correct has already been checked, or will be checked later on during the compile (which I don't doubt it already has, but at least see it better to have some sort of sanitisation when checking things).
(In reply to comment #7) > > > > Eh? What makes you think it isn't? > > Well, from what I can tell, if I were to have the following code excerpt: > > int[] a = [1]]; > > The scan ahead routine will swallow the "[1]", and since (--brackets == 0), > takes a peek at the last bracket, to which it matches in the if statement and > says 'yep, that is OK'. > In other words, it assumes that whether or not the above line is correct has > already been checked, or will be checked later on during the compile (which I > don't doubt it already has, but at least see it better to have some sort of > sanitisation when checking things). The scan ahead doesn't swallow anything. It does see only "[1]" and because (--brackets == 0) it says "I'm going to parse this as ArrayInitializer", which it does. The next loop (the ArrayInitializer rule) swallows "[1]", and no more. Then parseInitializer is done. The function that called parseInitializer (parseDeclarations or whatever), will expect a semicolon or comma to be the next token, and when it sees lbracket, it errors.
Created attachment 614 [details] the patch which I mistakenly put in 3716
http://www.dsource.org/projects/dmd/changeset/514