|
Last change
on this file since d60a4c2 was 81e768d, checked in by Michael Brooks <mlbrooks@…>, 10 months 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:
88 bytes
|
| Line | |
|---|
| 1 | bound_ptr_allow 999: 1.1 1.2 1.3
|
|---|
| 2 | bound_ar_allow 41:
|
|---|
| 3 | 1.1 1.2 1.3
|
|---|
| 4 | 2.1 2.2 2.3
|
|---|
| 5 | 3.1 3.2 3.3
|
|---|
Note:
See
TracBrowser
for help on using the repository browser.
