[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

test results differents between the perl and XS parsers

From: Patrice Dumas
Subject: test results differents between the perl and XS parsers
Date: Mon, 16 Nov 2020 11:28:23 +0100


It is not very important, but would be practical.  Right now the perl
parser and XS parser outputs are different in a non important way but
the difference makes the Data::Dumper dump of their results different
which makes looking at their difference somewhat impractical.  Not a big
deal, as it does not have any effect on the tests failing or passing.
So it is possible to regenerate the tests with the perl parser before
working on a change.  Still, could be nice if it could be fixed.  Here
is what I investigated.  The differences are like 

-      'line_nr' => {
-        'file_name' => '',
-        'line_nr' => 3,
-        'macro' => ''
-      },
+      'line_nr' => {},

+$result_trees{'alias_table_command'}{'contents'}[2]{'line_nr'} = 

In the perl parser, the two elements share the same 'line_nr' object, in
the XS parser they are duplicate.  One is in the 'extra' field of the
parent command.  Looking at the trees, it seems to happen with @*table*
(and maybe in other case, I haven't fully investicated as there are too
many).  I think that the perl parser is better in that case, the
whole 'extra' in the parent command should point to the element and avoid 
duplicating anything.

I tried to look at the C code to find where the reference to the 
extra in the parent is done in the case of @table and @vtable, 
and I found in parsetexi/parser.c l 1405
          add_extra_element (current->parent->parent,
                                 "command_as_argument", current);
Looking at extra.c, add_extra_element calls add_extra_key which does not
seem to duplicate the value but rather points to it.  So I am not sure
what's going on which leads to the duplication.  It could be related to
passing back to perl, it may be in the code in parsetexi/api.c near 
l 536, but I don't really get what is going on there.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]