>>> However, I'm not sure if the place where you do it is the most >>> preferable: I think it should rather go inside of >>> check_dummy_characteristics (since any check for the dummy >>> characteristics should include the 'strict' type check, and not only a >>> check of type compatibility, cf. F08:12.3.2.2). >> >> Okay. Maybe one can at the same time replace the rank+type check by a type >> and a rank check to provide a better error message, i.e. show the type for a >> type mismatch (showing both types)* and the rank for a rank mismatch >> (showing both ranks). > > yes, actually I also thought that splitting it up might be a good idea. > > >>> Moreover, I think your current patch misses e.g. the assumed-type >>> handling that is present in compare_type_rank. >> >> Good point. Another reason to think about splitting the two. > > Right. > > However, the question is whether the patch will not become too > involved for backporting.
Ok, so: How about the attached patch as a simple & backportable fix for the regression? (Ok for trunk/4.8/4.7?) I suggest the rest (i.e. splitting up compare_type_rank, improving error messages, etc) should be done in a follow-up patch on trunk only. (I might even volunteer do to this once I find the time ...) Cheers, Janus
pr57217.diff
Description: Binary data
