Fix Issue #22790: Allow static array parameters in ImportC

[oCHIKIo]

fixes #22790
by removing the hardcoded error in cparse.d that explicitly rejected the static keyword inside array parameters. since the compiler's underlying parser already handles the array type structure correctly, simply lifting this restriction allows the C99-compliant behavior to work naturally. I also updated the failcstuff1.c test suite so it no longer expects the compiler to fail when it encounters this syntax.

[dlang-bot]

Thanks for your pull request and interest in making D better, @oCHIKIo! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

⚠️⚠️⚠️ Warnings ⚠️⚠️⚠️

• In preparation for migrating from Bugzilla to GitHub Issues, the issue reference syntax has changed. Please add the word "Bugzilla" to issue references. For example, Fix Bugzilla Issue 12345 or Fix Bugzilla 12345.(Reminder: the edit needs to be done in the Git commit message, not the GitHub pull request.)

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#22800"

[oCHIKIo]

@kinke I ve added the _Static_assert to verify the array decays to a pointer. Let me know if everything looks good to merge!

[ibuclaw]

The important thing here is to check that the static array decays to the pointer, since static arrays are normally passed by value in D.

Further, are you following the other semantics as per C11 spec?

[oCHIKIo]

@ibuclaw yes, the array decays to a pointer perfectly. ImportC already adjusts array parameters to pointers automatically, and I included a _Static_assert(sizeof(array) == sizeof(int*)) in test22790_1.c to verify that the decay happens inside the function scope. regarding the other C11 semantics for static (guaranteeing a minimum number of elements), DMD doesn't enforce those boundary checks yet. however, parsing the static keyword correctly at least allows valid C99/C11 code using this feature to compile without syntax errors.

[ibuclaw]

I see.

6.7.6.2-1

The optional type qualifiers and the keyword static shall appear only in a declaration of a function parameter with an array type

then

and then only in the outermost array type derivation.

Both the above should be enforced with an error if one does not exist yet.

int fn(int arr[static 1][2]);  // Valid
int fn(int arr[1][static 2]);  // Error, static in non-parameter array declarator
int var[static 1][2];          // Error, static in non-parameter array declarator

---

6.7.6.3-7

If the keyword static also appears within the [ and ] of the array type derivation, then for each call to the function, the value of the corresponding actual argument shall provide access to the first element of an array with at least as many elements as specified by the size expression.

The following are all compatible function prototype declarators.

int fn(int (* restrict a)[5]);
int fn(int a[restrict][5]);
int fn(int a[restrict 3][5]);
int fn(int a[restrict static 3][5]);

int gn()
{
    int b[3][5];
    return fn(b);  // OK, no conflicts.
}

[ibuclaw]

DMD doesn't enforce those boundary checks yet

Bounds checks are not part of the spec. So I'd consider it something for an static analyzer to deal with.

[ibuclaw]

Likewise, do expressions work with this?

void f1 (int[static 1 + 1]);
void f2 (int a, int x[static sizeof a]);
// IIRC, we don't support VLA's yet.
void f3 (int a, int x[static a]);

[ibuclaw]

Finally, maybe a test for each [static expr] and [static qual expr] ?

i.e: This should compile.

void f1 (int a[static 2])
{
  int **b = &a;
  int *const *c = &a;
}

void f2 (a)
     int a[static 2];
{
  int **b = &a;
  int *const *c = &a;
}

void f3 (int a[static const 2])
{
  int **b = &a;
  int *const *c = &a;
}

void f4 (a)
     int a[static const 2];
{
  int **b = &a;
  int *const *c = &a;
}

[oCHIKIo]

@ibuclaw I ran those tests and it looks like DMD already handles the restrictions perfectly

the invalid placements like arr[1][static 2] already trigger Error: static or type qualifier used in non-outermost array type derivation.

for expressions, stuff like 1 + 1 works great. Things like sizeof a fail with undefined identifier 'a' because the parser doesn't put previous parameters in scope yet, but since we don't fully support VLAs yet anyway that's expected.

for the qualifiers, standard prototypes like int a[static const 2] compile without issue. K&R syntax variations do fail with a prototype error, but I'm assuming we're not too worried about K&R right now.

want me to add the working examples to the test file?