compiling code that #includes <valarray> on MacOS X 10.6 triggers this:
warning: class '_Array' was previously declared as a struct
[-Wmismatched-tags]
In file included from cint/cint/lib/dll_stl/G__cpp_valarray.cxx:7:
In file included from ./cint/cint/lib/dll_stl/G__cpp_valarray.h:32:
In file included from ./cint/cint/lib/dll_stl/vary.h:10:
In file included from /usr/include/c++/4.2.1/valarray:539:
/usr/include/c++/4.2.1/bits/valarray_after.h:62:24: note: in
instantiation of template class 'std::valarray<unsigned long>' requested
here
{ return _M_index.size(); }
^
In file included from cint/cint/lib/dll_stl/G__cpp_valarray.cxx:7:
In file included from ./cint/cint/lib/dll_stl/G__cpp_valarray.h:32:
In file included from ./cint/cint/lib/dll_stl/vary.h:10:
In file included from /usr/include/c++/4.2.1/valarray:91:
/usr/include/c++/4.2.1/bits/valarray_array.h:414:12: note: previous use
is here
struct _Array
^
Is this warning correct? If so: can you get your colleagues down the
hallway to fix it?
And probably it's just me, but I have a hard time understanding the
warning message itself: is it claiming that structs cannot be templated?
Where is the "class _Array" that mismatches the "struct _Array"?
template<typename T>
struct valarray
{
friend class _Array<T>;
};
valarray<int> a;
Note that the 'friend' declaration uses 'class', while the definition of _Array uses 'struct'.
This is probably a reasonable warning. it would be nice to suppress all warnings from system headers. There is an easy fix, but it would cause another difference between Mac OS X's copy of libstdc++ and the original one provided by g++, and wouldn't fix the issue on linux.
Chris
Hi,
compiling code that #includes <valarray> on MacOS X 10.6 triggers this:
warning: class '_Array' was previously declared as a struct
[-Wmismatched-tags]
In file included from cint/cint/lib/dll_stl/G__cpp_valarray.cxx:7:
In file included from ./cint/cint/lib/dll_stl/G__cpp_valarray.h:32:
In file included from ./cint/cint/lib/dll_stl/vary.h:10:
In file included from /usr/include/c++/4.2.1/valarray:539:
/usr/include/c++/4.2.1/bits/valarray_after.h:62:24: note: in
instantiation of template class 'std::valarray<unsigned long>' requested
here
{ return _M_index.size(); }
^
In file included from cint/cint/lib/dll_stl/G__cpp_valarray.cxx:7:
In file included from ./cint/cint/lib/dll_stl/G__cpp_valarray.h:32:
In file included from ./cint/cint/lib/dll_stl/vary.h:10:
In file included from /usr/include/c++/4.2.1/valarray:91:
/usr/include/c++/4.2.1/bits/valarray_array.h:414:12: note: previous use
is here
struct _Array
^
Is this warning correct? If so: can you get your colleagues down the
hallway to fix it?
The problem is that 'struct _Array' is used in valarray_array.h, while
Note that the 'friend' declaration uses 'class', while the definition of _Array uses 'struct'.
Thanks for spotting it! Would clang have a chance to also put that
location into the warning, instead of only the (in this case irrelevant)
location of the instantiation?
It would be nice to suppress all warnings from system headers.
I agree! It would be nice to have an option for it, like -wsystem.
I agree! It would be nice to have an option for it, like -wsystem.
One of my colleagues pointed this issue out to me a while back too. I took a quick look but wasn’t able to figure out why the warning isn’t being suppressed (I’m not particularly familiar with clang). I opened http://llvm.org/bugs/show_bug.cgi?id=8129 to track the issue.
I agree! It would be nice to have an option for it, like -wsystem.
We actually suppress warnings in system headers by default.
One of my colleagues pointed this issue out to me a while back too. I took a quick look but wasn’t able to figure out why the warning isn’t being suppressed (I’m not particularly familiar with clang). I opened http://llvm.org/bugs/show_bug.cgi?id=8129 to track the issue.
It’s not being suppressed because the diagnostic is triggering at an invalid location. That’s why the warning doesn’t have line/column information or a caret display. We’re probably just not preserving information correctly into template instantiation in this case.
It would be nice to have an option for it, like -wsystem.