source: tests/.expect/tuplearray.txt @ 94aa202

Last change on this file since 94aa202 was 81e768d, checked in by Michael Brooks <mlbrooks@…>, 3 weeks ago

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.
  • Property mode set to 100644
File size: 100 bytes
Line 
11, 2
21, 2
31, 2
41, 2
51, 2
61, 2
71, 2
81, 2
91, 2
101, 2
112, 4
122, 4
132, 4
142, 4
152, 4
162, 4
172, 4
182, 4
192, 4
202, 4
Note: See TracBrowser for help on using the repository browser.