Fix #276; add support for c-array parameters using dependent lengths. (details)
Update the enumeration proposal with some updates now that the rework is complete. Deleted the old thesis draft. (details)
Try to fix arch-specific test failure from my last commit (details)
Try 2 to fix arch-specific test failure from my last commit (details)
Commit
81e768d1c7e5b625cf5e14ca13ea80c649602ad5
by Michael Brooks
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.