184002 - configure test for extern template specializations

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Benjamin Smedberg]

For bug 180264 I will need a configure test, whether compilers support extern
template specializations. I have a patch that I think will work.

Comment 1

[Benjamin Smedberg]

Attachment: diff -u of configure.in

Comment 2

[hacker formerly known as [e-mail]]

Our resident language lawyers will have to review the test.  I'm not worthy.

Comment 3

[John Keiser (jkeiser)]

bbaetz is another great guy to review this.

Comment 4

[Bradley Baetz (:bbaetz)]

I'm confused. I don't see this used in teh patch on bug 180264. From that bug:

"If the compiler does not support this syntax, we can degrade gracefully by
omitting the extern declaration (at the price of a little code duplication):

extern template myClass<T>;"

I'm not really sure that that will work, though. |extern template| is an
extention, AFAIK - does it even mean the same thing on all compilers?

I'm also not sure how much code duplication there will be, anyway - g++ uses
.linkonce sections to only have the resulting function appear once anyway.

Won't the |extern| suppress inlining, though, whcih is what you're trying to
avoid for bug 180264? (I'm not too sure about that bit, though)

Comment 5

[Benjamin Smedberg]

The basic idea of this syntax is to avoid duplicate instantiations of template
functions *across shared-libraries*.  Compilers fold duplicate instantiations
within a single library, but not across shared libraries.  Instantiate all of
the common templatizations of nsTHashtable within the XPCOM shared lib, and it
won't need to be duplicated in other shared libs.

"extern template class" is an extension, but it has a standard meaning on GCC
and MSVC: it declares all the class functions with external linkage, just like
"extern var".

I want to add this test to bug 180264, because I know that this syntax breaks
mac compilers, and others I'm sure. I would wrap the "extern template class"
declarations in an #ifdef HAVE_CPP_EXTERN_INSTANTIATION to protect Mac and other
compilers that don't support the external linkage.

> Won't the |extern| suppress inlining, though, whcih is what you're trying to
> avoid for bug 180264? (I'm not too sure about that bit, though)

"extern class" shouldn't suppress inlining, but that isn't the point of bug
180264 in any case.  That bug avoids multiple heap allocations in hashtables, by
allocating keys and data "inline" in the hashtable.

Comment 6

[Benjamin Smedberg]

Attachment: patch version 2 (includes changes to nscore.h)

I forgot, that since we don't support configure tests for MSVC, that it had to
be declared manually in nscore.h for Win32 platforms.

Comment 7

[Benjamin Smedberg]

Attachment: patch -u without CRs

Same patch, without carriage returns.

Comment 8

[Scott Collins]

Comment on attachment 109224 [details] [diff] [review]
patch -u without CRs

and did you find that the results from this test matched the actual
capabilities of the compilers?	It looks like a reasonable test to me.

r=scc

Comment 9

[Scott Collins]

depending on the result of discussion about maintaining the classic Mac build,
I'll test Metrowerks for compliance and add the appropriate declaration to the
Mac flags section

Comment 10

[hacker formerly known as [e-mail]]

Patch has been checked in.

Comment 11

[Benjamin Smedberg]

Verifying... tinderbox logs look reasonable.  Thanks, cls and scc!