bug#47408: [PATCH] Etags support for Mercury -- fix explicit tags for existentially-quantified procedures

[fabrice nicol]

Agreed. (But you may have more systematically explicit tags because of 
this condition 2.)

The attached patch was tested, builds and runs OK. Replaces the former 
one, is you stick to the option of modifying 's' by reference rather 
than creating a copy.

Note: Prolog has a much simpler naming pattern, so differences are 
normal. No need for explicit tagging in Prolog, see the call to 
'make_tag' in Prolog support.

Fabrice

Le 14/06/2021 à 19:42, Eli Zaretskii a écrit :
> > Cc: 47408@debbugs.gnu.org, pot@gnu.org
> > From: fabrice nicol <fabrnicol@gmail.com>
> > Date: Mon, 14 Jun 2021 19:10:53 +0200
> >
> > If you take a look at other languages that implement explicit tags (like
> > Fortran) you will see that there are buffers coming in to avoid having
> > 'name' and 'linestart' (1st and 4th arguments to 'make_tag') share a
> > same string pointer (here 's').
> >
> > This is explained in the header comment to 'make_tag':
> >
> > " 2. LINESTART contains name as either a rightmost, or rightmost but
> >    *     one character, substring;"
> This is just a condition for generating "implicitly named" tags.
> There's nothing wrong with having explicitly named tags, if there are
> good reasons for that.
>
> > When I applied you suggestion and tested, the TAGS base was as expected
> > accordingly: wrong.
> "Wrong" in what sense?  Can you show an example of such a wrong tag?
> And how does Mercury differ from Prolog in this sense? prolog_pr
> doesn't allocate new strings before calling make_tag.
>
> Thanks.

0001-Fix-explicit-tag-issue-with-Mercury-etags-ctags-supp-v2.patch
Description: Text Data