GNU bug report logs - #34789
mantemp.el should be obsoleted

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 34789 in the body.
You can then email your comments to 34789 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: bug-emacs <bug-gnu-emacs <at> gnu.org>
Subject: mantemp.el should be obsoleted
Date: Fri, 8 Mar 2019 11:16:27 -0800

Davis Herring writes, "One of your fixes was to progmodes/mantemp.el,
which (now that I know it exists) I'm pretty sure should be obsoleted;
as you may already know, C++ compilers haven't worked that way for any
standard library type (and most user-defined types) in a very long time."

I notice that no significant changes have been made to mantemp.el since
1997. As it's evidently useless nowadays, I propose that we move
mantemp.el to the obsolete area, and remove it in a later Emacs release.

Message #8 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 34789 <at> debbugs.gnu.org
Subject: Re: bug#34789: mantemp.el should be obsoleted
Date: Fri, 08 Mar 2019 21:51:29 +0200

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 8 Mar 2019 11:16:27 -0800
> 
> Davis Herring writes, "One of your fixes was to progmodes/mantemp.el,
> which (now that I know it exists) I'm pretty sure should be obsoleted;
> as you may already know, C++ compilers haven't worked that way for any
> standard library type (and most user-defined types) in a very long time."
> 
> I notice that no significant changes have been made to mantemp.el since
> 1997. As it's evidently useless nowadays, I propose that we move
> mantemp.el to the obsolete area, and remove it in a later Emacs release.

If no compiler can ever be helped by that feature, I think I agree.
But I'd like first to hear in more detail why "C++ compilers haven't
worked that way for any standard library type (and most user-defined
types) in a very long time."  We should at least have this information
recorded here for posterity.

Thanks.

Message #11 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Davis Herring <herring <at> lanl.gov>
To: 34789 <at> debbugs.gnu.org
Subject: Re: Scan of regexp mistakes
Date: Fri, 8 Mar 2019 13:46:38 -0700

> But I'd like first to hear in more detail why "C++ compilers haven't
> worked that way for any standard library type (and most user-defined
> types) in a very long time."  We should at least have this information
> recorded here for posterity.

The situation in question (based on the comments in mantemp.el) concerns 
code like

  #include<vector>
  int main() {
    std::vector<double> v(1);
    return *v.begin();  // 0
  }

where, once upon a time, the compiler would emit undefined references to 
functions like "std::vector<double>::begin()" that had to be explicitly 
instantiated (in a single translation unit chosen by the user).  (The 
age of this era is indicated by the missing "std::" in the example error 
messages.)

In all compilers newer than about 2003, such functions are automatically 
_generated_ when used, so that there are no undefined references (and no 
need to manually request instantiation).  It is still _possible_ to 
instantiate things this way for performance reasons in certain 
complicated cases, but you have to ask for it:

  // foo.hxx
  #ifndef FOO_HXX
  #define FOO_HXX
  #include<vector>
  struct A {};    // a user-defined type must be involved
  extern template class std::vector<A>;  // block implicit instantiation
  #endif

  // templates.cxx
  #include"foo.hxx"
  // The one shared instantiation, as mantemp.el could generate:
  template class std::vector<A>;

  // client.cxx
  #include"foo.hxx"
  vector<A> gv;       // relies on templates.cxx

  // possibly more clients...

  // main.cxx
  #include"foo.hxx"
  int main() {
    vector<A> v;      // relies on templates.cxx
    return v.size();
  }

(This is C++11 code; in C++03, only user-defined types can be made to 
behave this way, and it's harder.)

This style of code is rare, and will if anything become rarer still in 
C++20, when code in a header file that uses a particular specialization 
(e.g., std::vector<A>) can be put into a module that is compiled only 
once.  Even if someone were doing this, mantemp.el could at most 
generate the one indicated line in templates.cxx _after_ the very 
similar line in foo.hxx was added in some other fashion.

Hope this helps clarify,
Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.

Message #14 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Davis Herring <herring <at> lanl.gov>
Cc: 34789 <at> debbugs.gnu.org
Subject: Re: bug#34789: Scan of regexp mistakes
Date: Mon, 11 Mar 2019 16:20:40 +0200

> From: Davis Herring <herring <at> lanl.gov>
> Date: Fri, 8 Mar 2019 13:46:38 -0700
> 
> This style of code is rare, and will if anything become rarer still in 
> C++20, when code in a header file that uses a particular specialization 
> (e.g., std::vector<A>) can be put into a module that is compiled only 
> once.  Even if someone were doing this, mantemp.el could at most 
> generate the one indicated line in templates.cxx _after_ the very 
> similar line in foo.hxx was added in some other fashion.
> 
> Hope this helps clarify,

Thanks, it does.  I think we indeed should move this package into
obsolete/.

Message #17 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: 34789 <at> debbugs.gnu.org
Cc: Davis Herring <herring <at> lanl.gov>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#34789: Scan of regexp mistakes
Date: Thu, 13 Jun 2019 14:13:45 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
> Thanks, it does.  I think we indeed should move this package into
> obsolete/.

Does this patch do the job?

Thanks,
Stefan Kangas

[0001-lisp-progmodes-mantemp.el-Move-to-obsolete-.-bug-347.patch (application/octet-stream, attachment)]

Message #20 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: herring <at> lanl.gov, 34789 <at> debbugs.gnu.org
Subject: Re: bug#34789: Scan of regexp mistakes
Date: Thu, 13 Jun 2019 15:48:48 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 13 Jun 2019 14:13:45 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Davis Herring <herring <at> lanl.gov>
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > Thanks, it does.  I think we indeed should move this package into
> > obsolete/.
> 
> Does this patch do the job?

Works for me, but I'm not sure we have the procedure for obsoleting a
package documented anywhere, so maybe something else needs to be
done.  Anyone?

Message #23 received at 34789 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Davis Herring <herring <at> lanl.gov>, 34789 <at> debbugs.gnu.org
Subject: Re: bug#34789: Scan of regexp mistakes
Date: Thu, 13 Jun 2019 15:42:40 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:
> > > Thanks, it does.  I think we indeed should move this package into
> > > obsolete/.
> >
> > Does this patch do the job?
>
> Works for me, but I'm not sure we have the procedure for obsoleting a
> package documented anywhere, so maybe something else needs to be
> done.  Anyone?

I had a look at this:
https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commit;h=ef65424de8cae00209f6a0974245822602709df3

And did some improvements, see attached patch.

Thanks,
Stefan Kangas

[0001-Move-mantemp.el-to-obsolete.patch (application/octet-stream, attachment)]

Message #28 received at 34789-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: herring <at> lanl.gov, 34789-done <at> debbugs.gnu.org
Subject: Re: bug#34789: Scan of regexp mistakes
Date: Sat, 22 Jun 2019 12:09:30 +0300

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Thu, 13 Jun 2019 15:42:40 +0200
> Cc: 34789 <at> debbugs.gnu.org, Davis Herring <herring <at> lanl.gov>
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > > > Thanks, it does.  I think we indeed should move this package into
> > > > obsolete/.
> > >
> > > Does this patch do the job?
> >
> > Works for me, but I'm not sure we have the procedure for obsoleting a
> > package documented anywhere, so maybe something else needs to be
> > done.  Anyone?
> 
> I had a look at this:
> https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=commit;h=ef65424de8cae00209f6a0974245822602709df3
> 
> And did some improvements, see attached patch.

Thanks, pushed.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.