Fix #276; add support for c-array parameters using dependent lengths.
Without this fix, declarations like
void f( int m, int n, float[m][n] );
would either
- generate bad C code, with unmangled variable names appearing in the function definition, or
- refuse to resolve a valid-c call of such a function.
tests/array-collections/c-dependent: add direct tests of such cases
tests/tuplearray: activate and expand cases which were blocked on #276
tests/array: activate case fm5y, which was blocked on #276; [noise] adjust source line numbers in .expect
tests/typedefRedef: expand coverage of "error, an array detail is different" cases; [noise] adjust source line numbers in .expect
tests/functions: [noise] adjust .expect to have resolved array sizes (extra casts) in the diffed code dump
The fix is:
- (ResolvExpr/ResolveTypeof?, ResolvExpr/Resolver?) Resolve the dimension expressions, where they were missed.
- (ResolvExpr/Resolver?) Prevent dimension expressions that are bound to other parameters from escaping in the function's type, to where they are out of scope. In the f example above, redact the type shown to callers from
void (*)(int, int, float[m][n]) to void (*)(int, int, float[][*]).
- (ResolvExpr/Unify?) Relax the matching rules for such a type, when used at a call site, letting the patameters wildcard type match with the concrete type in scope at the caller's side.
- (Validate/ReplaceTypedef?) Apply the former, stricter matching rules to the one place where they are still needed: detecting inconsistent typedefs.
