[Ada] Secondary stack leak in "for X of ..." loops
This patch fixes a memory leak bug. In particular, in a loop of the form "for X of ...", with a type that has the Iterable aspect specified, if the result of the Element function is returned on the secondary stack (e.g. the result subtype has caller-unknown size), then memory for the secondary stack could leak. 2018-05-30 Bob Duff <duff@adacore.com> gcc/ada/ * exp_ch5.adb (Expand_Formal_Container_Element_Loop): Remove the code to analyze the Elmt_Decl, because it gets analyzed in the wrong scope. We need to analyze it as part of analyzing the block, so that if the call to Element that initializes Elmt_Decl returns on the secondary stack, the block will ss_mark/ss_release. This block is inside the loop; we don't want to leak memory until the loop exits. The purpose of analyzing Elmt_Decl first was to catch the error of modifying it, which is illegal because it's a loop parameter. The above causes us to miss that error. Therefore, we add a flag Is_Loop_Parameter, and set it on the Element entity, so we end up with an E_Variable node with the flag set. * einfo.ads, einfo.adb (Is_Loop_Parameter): New flag. * sem_ch5.adb (Diagnose_Non_Variable_Lhs): Give the "assignment to loop parameter not allowed" error if Is_Loop_Parameter. * sem_util.adb (Is_Variable): Return False if Is_Loop_Parameter, to trigger the call to Diagnose_Non_Variable_Lhs. From-SVN: r260930
Showing
Please
register
or
sign in
to comment