Re: [PATCH v2] Logical short circuiting with argument lists

[Richard Bunt <richard.bunt@arm.com>]

On 09/07/2018 11:23 PM, Tom Tromey wrote:
>>>>>> "Richard" == Richard Bunt <richard.bunt@arm.com> writes:


> 
> I wonder if we really want this to error in the case where the symbol
> isn't found.  But I suppose it is necessary for your patch to work.
> 
> I tend to think it is fine; I couldn't think of a plausible,
> non-pathological way that I would want to use the non-erroring behavior.

If I understand correctly the concern here is that the evaluation will
report an error if the symbol is not found, even if it is supposed to be
evaluated in a lazy manner. I considered a similar issue when testing
with the following expression:

print k .OR. array(1,2,3,4)

where k == .TRUE. and array only has 3 dimensions. The debugger still
reports that this is invalid even though the array access is not needed
for the truth value. I considered this to be acceptable as this code
wouldn't compile anyway and I would rather it failed fast than at some
point later (when k becomes false). I believe a similar justification 
holds for the case where array is an invalid symbol.

> 
> Though, another option is to do this in a fortran-specific way.

Are you able to provide some more details on this approach please?

> 
> Richard> +	gdb_test "p .TRUE. .OR. binary_string($range1) .OR. truth_table($range2, 1)" \
> 
> For some of the tests -- I'm afraid I didn't enumerate them -- you will
> need to supply a different (and unique) test name to gdb_test, because
> there is a rule against tests having parenthesized text at the end of
> their name:
> 
> https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages
> 
> Tom
> 

Based on the discussion with Simon I understand that there is no issue
here. However, if I had used a space between the array symbol name
and the parenthesizes this would have been a problem. This is useful to
know.

Missing comments, style errors and non-idiomatic code have been fixed
in v3.

Many thanks for the comments,

Rich.