ada: Deconstruct Safe_To_Capture_In_Parameter_Value
authorPiotr Trojanek <trojanek@adacore.com>
Tue, 19 May 2020 19:07:07 +0000 (21:07 +0200)
committerMarc Poulhiès <poulhies@adacore.com>
Mon, 7 Nov 2022 08:36:33 +0000 (09:36 +0100)
commit214b1cb8a829568c7ef675b7c3e6a2d8b9a96875
tree2281e20fb9740e301666829d91a691a3392587e1
parentbb513a0d0f5e88b65abbab304692622f40641694
ada: Deconstruct Safe_To_Capture_In_Parameter_Value

Recently routine Safe_To_Capture_Value was adapted, so that various data
properties like validity/nullness/values are tracked also for
in-parameters. Now a similar routine Safe_To_Capture_In_Parameter_Value,
which was only used to track data nullness, is redundant, so this patch
deconstructs it.

Also the removed routine had at least few problems and limitations, for
example:

1) it only worked for functions and procedures, but not for protected
entries and task types (whose discriminants work very much like
in-parameters)

2) it only worked for subprogram bodies with no spec, because of this
dubious check (here simplified):

   if Nkind (Parent (Parent (Current_Scope))) /= N_Subprogram_Body then
       return False;

3) it only recognized references within short-circuit operators as
certainly evaluated if they were directly their left hand expression,
e.g.:

   X.all and then ...

but not when they were certainly evaluated as part of a bigger
expression on the left hand side, e.g.:

   (X.all > 0) and then ...

4) it categorizes parameters with 'Unrestricted_Access attribute as safe
to capture, which is not necessarily wrong, but risky (because the
object becomes aliased).

Routine Safe_To_Capture_Value, which is kept by this patch, seems to
behave better in all those situations, though it has its own problems as
well and ideally should be further scrutinized.

gcc/ada/

* checks.adb (Safe_To_Capture_In_Parameter_Value): Remove.
* sem_util.adb (Safe_To_Capture_Value): Stop search at the current
body.
gcc/ada/checks.adb
gcc/ada/sem_util.adb