Dear Mikael, > I think there are a couple of bugs not triggered by the single component > types in the test. See below.
Yes, you are right. We should have tested multiple components... my fault! > This could be moved to the only next caller (`previous' doesn't need to > be updated if `this_code' is removed) to fix one usage of `this_code' :-). That's right... I'll make it so. > ... but I have the feeling that this makes (*code) unreachable and that > that's wrong. Shouldn't it be "root->next = *code;" ? No. That caused the regression that I mentioned. (*code) is resolved, at entry. resolve_code steps on to (*code)->next. > if we do it after the typebound calls, we overwrite their job so we have > to do it before. This is what is done. > However, if we do it before, we also overwrite components to be assigned > with a typebound call, and this can have some side effects as the LHS's > argument can be INTENT(INOUT). This might be so but it is what the standard dictates should happen.... isn't it? Thanks for the review. I believe, in summary, that I should handle 'this_code' consistently so that multiple component defined assignments work correctly. I should also verify that pointers do what they are supposed to do, although it is rather trivial. Cheers Paul
