[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: warnings shut off in ov.cc?
From: |
Rik |
Subject: |
Re: warnings shut off in ov.cc? |
Date: |
Tue, 15 Oct 2019 14:13:52 -0700 |
On 10/15/2019 01:26 PM, John W. Eaton wrote:
> On 10/15/19 2:21 PM, Rik wrote:
>> jwe,
>>
>> Can you try the attached patch which implements a warning when non-scalar
>> arguments are used with the colon operator? Everything looks correct, and
>> the printf debugging that I started using when I got confused shows that
>> the code is executing, but no warnings are printed. The code is exactly
>> the same format as the warning for complex values using in colon
>> expressions, however that warning fires. Is there something that disables
>> warnings temporarily in the interpreter when calling operators?
>>
>> Sample session:
>>
>> 1:[3,4]
>> running do_colon_op
>> Got here
>> Got here2
>> ans =
>>
>> 1 2 3
>>
>> whereas
>>
>> octave:1> 1:3*i
>> running do_colon_op
>> warning: imaginary part of complex colon arguments is ignored
>> ans = [](1x0)
>>
>> Maybe this is a red herring, but occasionally warnings seem to be turned
>> off for the complex code path as well.
>>
>> octave:2> 1:(3i)
>> running do_colon_op
>> ans = [](1x0)
>>
>> The last example should also have produced a warning.
>
> I think you are seeing the effect of constant folding in the parser:
>
>
> http://hg.savannah.gnu.org/hgweb/octave/file/5a0543de1e47/libinterp/parse-tree/oct-parse.yy#l2493
>
>
> Warnings are intentionally disabled when doing constant folding
> operations. The original idea may have been the same as what we should
> be doing for errors, which is to be silent about them when attempting
> constant folding, but if there is an error (or warning), fail to generate
> a constant value so that the expression will generate an error (or
> warning) later at run time. This is clearly not happening for warnings.
>
> Unfortunately, I don't think that skipping the message but detecting the
> warning is an easy thing to do.
>
> Maybe we should just eliminate the constant folding operations in the
> parser? I'm not sure that they really provide that much advantage.
Thanks, that is definitely the issue. I tried two ways of making the
expression non-constant and, sure enough, the warning appears.
x = 4
1:[x, 10]
and
1:[3+1, 10]
What about just not discarding warning messages? I commented out this line
// es.discard_warning_messages (true);
and then everything works as expected (no duplicate warning messages either).
Just to be sure, I added more printf test code and even though the warning
is issued, the path through the constant logic is still taken. Maybe the
unwind_protect frame is only required to capture errors, but warnings are
fine since they return to the original code and it keeps executing?
--Rik