PassRefPtr.h fails to compile under VS2010 RC. This line: friend PassRefPtr adoptRef<T>(T*); generates a C4396 error: "the inline specifier cannot be used when a friend declaration refers to a specialization of a function template". See http://msdn.microsoft.com/en-us/library/bb384968.aspx for more details.
Sorry, that's a warning, not an error. We should probably just disable this warning in common.vsprops.
I think this warning also affects VS2008.
Hi, I just submitted a patch for this. See bug 34828. There are actually three files in JavaScriptCore project, which are affected. I managed to build it with VS2008. Safari works fine.
I do not think you should disable this warning in common.vsprops because accordingly to Microsoft: "The compiler issues warning C4396 and IGNORES THE INLINE SPECIFIER." http://msdn.microsoft.com/en-us/library/bb384968.aspx I am pretty sure that VS2005 compiler as well as many others also ignored inline specifier in that particular case, but without warning. :)
*** Bug 34828 has been marked as a duplicate of this bug. ***
As described in bug 34828, this affects a few other WTF headers.
<rdar://problem/8234558>
(In reply to comment #4) > I do not think you should disable this warning in common.vsprops because accordingly to Microsoft: "The compiler issues warning C4396 and IGNORES THE INLINE SPECIFIER." http://msdn.microsoft.com/en-us/library/bb384968.aspx > I am pretty sure that VS2005 compiler as well as many others also ignored inline specifier in that particular case, but without warning. :) I think the way to make a decision here is roughly: * Does any compiler honor the inline specifier on adoptRef? * No: we should just remove it * Yes: * Does removing the inline specifier have any negative effects for those compilers which honor it? * No: we should just remove it * Yes: we should ignore the warning
Created attachment 188561 [details] Patch proposed for removing inline statement in order to compile under VS2008
(In reply to comment #8) > (In reply to comment #4) > > I do not think you should disable this warning in common.vsprops because accordingly to Microsoft: "The compiler issues warning C4396 and IGNORES THE INLINE SPECIFIER." http://msdn.microsoft.com/en-us/library/bb384968.aspx > > I am pretty sure that VS2005 compiler as well as many others also ignored inline specifier in that particular case, but without warning. :) > > I think the way to make a decision here is roughly: > > * Does any compiler honor the inline specifier on adoptRef? > * No: we should just remove it > * Yes: > * Does removing the inline specifier have any negative effects for those compilers which honor it? > * No: we should just remove it > * Yes: we should ignore the warning Hello, Any news about this problem ? I am currently trying to compile webkit using VS2008 and I encountered this issue. As mentionned in Bug 34828, there are 3 inline statements that should be removed in order to compile under VS2008 (I submitted a patch).
Created attachment 188575 [details] Patch proposed for removing inline statement in order to compile under VS2008 (updated)
Comment on attachment 188575 [details] Patch proposed for removing inline statement in order to compile under VS2008 (updated) View in context: https://bugs.webkit.org/attachment.cgi?id=188575&action=review Patch is incorrect, at least for non-Microsoft compilers, has no change log, and also does not apply successfully. > JavaScriptCore/heap/PassWeak.h:162 > -template<typename T> PassWeak<T> inline adoptWeak(WeakImpl* impl) > +template<typename T> PassWeak<T> adoptWeak(WeakImpl* impl) This is an unacceptable change for other compilers. The inline keyword tells the compiler to inline this function. Not sure why Microsoft’s compiler is having a problem with this, but please don’t punish all others for this mistake.
Sorry, I see now that others suggest that perhaps all the compilers are ignoring this inline unless inline was specified in the friend declaration. To make this change we need to get data on that. Adam Roben described the research that needs to be done. If someone does that research then we can make the appropriate change.