[m-dev.] --warn-non-tail-recursion and deep profiling
Julien Fischer
jfischer at opturion.com
Wed Mar 2 13:22:27 AEDT 2016
On Wed, 2 Mar 2016, Paul Bone wrote:
> On Wed, Mar 02, 2016 at 12:33:22PM +1100, Julien Fischer wrote:
>>
>> Hi Paul,
>>
>> On Wed, 2 Mar 2016, Paul Bone wrote:
>>
>>> On Wed, Mar 02, 2016 at 10:13:24AM +1100, Julien Fischer wrote:
>>>>
>>>> Hi,
>>>>
>>>> Was it intended that --warn-non-tail-recursion should emit warnings
>>>> in deep profiling grades? Since those grades disable tail recursion
>>>> you obviously get a warning about every recursive predicate.
>>>
>>> Not specifically.
>>>
>>> Because this is disabled by default simply enabling deep profiling won't
>>> cause these warnings. A user giving both options on the command line will
>>> very quickly figure out what is happening, but if --warn-non-tail-recursion
>>> is specified in a Mercury.options file, especially if it's setup by another
>>> developer on a team, then enabling --deep-profiling might cause some
>>> surprise.
>>
>> That is the case I'm looking at. Specifically, I'm looking at the
>> "failure" of the test case invalid/require_tailrec_2 in the grade
>> none.gc.profdeep.trseg.stseg. We get additional warnings for this test
>> case because tail recursion is disabled. There are various ways to
>> avoid this failure (e.g. extra expected output, don't run the test in
>> profdeep grades); I'm trying to determine which one to use here.
>
> I suggest not running these tests with the profdeep grade component.
At least part of that test involves the warning about a
require_tail_recursion pragma on a non-recursive predicate. That at
least, ought to work in profdeep grades. I'll add an alternative
expected output for this one.
...
> Another option is if deep profiling and --warn-non-tail-recursive are both
> enabled, emit one general warning only. The text of the warning message
> could even change depending on the stseg grade component.
Rather than a warning, I think a single informational message (per
affected module) along those lines would be better.
Julien.
More information about the developers
mailing list