GNU bug report logs -
#34789
mantemp.el should be obsoleted
Previous Next
Reported by: Paul Eggert <eggert <at> cs.ucla.edu>
Date: Fri, 8 Mar 2019 19:17:02 UTC
Severity: minor
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
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.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Fri, 08 Mar 2019 19:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 08 Mar 2019 19:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Fri, 08 Mar 2019 19:52:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 34789 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Fri, 08 Mar 2019 21:19:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 34789 <at> debbugs.gnu.org (full text, mbox):
> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Mon, 11 Mar 2019 14:21:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 34789 <at> debbugs.gnu.org (full text, mbox):
> 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/.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Thu, 13 Jun 2019 12:15:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 34789 <at> debbugs.gnu.org (full text, mbox):
[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)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Thu, 13 Jun 2019 12:50:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 34789 <at> debbugs.gnu.org (full text, mbox):
> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#34789
; Package
emacs
.
(Thu, 13 Jun 2019 13:43:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 34789 <at> debbugs.gnu.org (full text, mbox):
[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)]
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>
:
You have taken responsibility.
(Sat, 22 Jun 2019 09:10:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Paul Eggert <eggert <at> cs.ucla.edu>
:
bug acknowledged by developer.
(Sat, 22 Jun 2019 09:10:03 GMT)
Full text and
rfc822 format available.
Message #28 received at 34789-done <at> debbugs.gnu.org (full text, mbox):
> 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.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Sat, 20 Jul 2019 11:24:05 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 348 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.