Re: [Boost-users] [signals2][variant] inline warning with MSVC 2022

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2022-09-23 12:40:40

On 9/23/22 14:06, Alexander Grund via Boost wrote:
> Am 23.09.22 um 11:59 schrieb Andrey Semashev via Boost:
>> There's no middle ground behavior between inline keyword and
>> BOOST_FORCEINLINE, so I don't see the reason to have yet another
>> BOOST_INLINE macro. You want opportunistic inlining - use plain inline.
>>
>> If __pragma/_Pragma approach doesn't work, I'm inclined to shift the
>> burden to library maintainers (those who are willing to deal with this)
>> and users. To users: you've brought this on yourselves by using -Werror
>> and -Wextra (or whatever equivalents your compiler has), so you pay the
>> price by having to deal with this. Using max warnings, especially if
>> promoted to errors, is useless and a bad idea.
>>
>> That said, I'm still in favor of an MSVC-specific fix by adding
>> __pragmas to BOOST_FORCEINLINE. That pesky warning has come up a few
>> times in the libraries I maintain and I never found it useful.
> 
> How can you say that there is no middle-ground between inline and
> BOOST_FORCEINLINE
> but still want warnings disabled by default when the compiler
> doesn't do what the macro name suggests it is told to?
> 
> The MSVC variant to what BOOST_FORCEINLINE expands to means inlining
> even with debug builds.

__forceinline does not work in debug builds.

https://godbolt.org/z/v3srxv3sr

OTOH, gcc's always_inline does.

https://godbolt.org/z/97rMTKv9r

As I said, BOOST_FORCEINLINE is not a guarantee that the function will
be inlined. It is used as an optional hint. The fact that a certain call
was not inlined is not an error, meaning that it is an expected
possibility, however unfortunate it is. Which means that the warning is
informational at best, and completely useless most of the time. I have
not had a case when I wanted to see it, nor have I heard of someone
wanting it, therefore I want to disable it.

Now, I see that gcc's always_inline is intended to be stronger than
that. However, in practice it showed to be an acceptable alternative to
__forceinline - BOOST_FORCEINLINE has been defined like that for
decades, and I don't remember anyone having a problem with that.

If anything, there could be a need for a new macro that triggers an
error if inlining fails, which is exactly what gcc's always_inline
gives. But so far there were no requests for such a macro.