[llvm-bugs] [Bug 24425] Unexpected divergence between -fmodules and not (due to "<undeserialized declarations>"?)

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=24425

Sean Silva <chisophugis at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #5 from Sean Silva <chisophugis at gmail.com> ---
(In reply to comment #4)
> (In reply to comment #3)
> > It's actually not clear to me what `template <typename T> char
> > Foo<T>::s_bar;` in the .cpp file even means from a language perspective.
> > Since it is templated, this doesn't really concretely define anything, so
> > what is its purpose? (forgive my ignorance of this part of the language)
> 
> This is providing a definition for the static data member. It's a bit weird
> that the language requires this, but the idea is that it's a template from
> which you would instantiate a definition of the static data member ("char
> Foo<int>::s_bar;"), and you can put an initializer there and the like.

Okay, I can see it now. Makes sense to be able to do `template <typename T>
char Foo<T>::s_bar = traits<T>::baz;` or the like.

> 
> The code as it stands is a more complex variant of this:
> 
> a.h:
> 
> template<typename T> void f();
> inline void g() { f<int>(); }
> 
> a.cpp:
> 
> template<typename T> void f() {}
> 
> ... which is a very broken thing to try to do.

Ah! makes perfect sense! This is a lot clearer for me intuitively from the
perspective of functions.

Since this arose in the wild, I'm going to follow up internally and investigate
a bit more exactly how this came up and how much of a chance users would have
at working around this if they encountered it (and also how likely they are to
encounter it).

If this turns out to be a showstopper for modules in the wild, we'll have to
investigate a way to rectify the situation, but that may be done better as a
check in modularize, clang-tidy, or whatever than as a change in the core of
the compiler.

It will be a separate discussion and issue anyhow, so marking this bug as
INVALID.

Thanks for all your help Richard!

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150812/ed5f9400/attachment-0001.html>