r202131 - Attr: Remove ForceInline

[Aaron Ballman]

On Tue, Feb 25, 2014 at 1:09 PM, David Majnemer
<david.majnemer at gmail.com> wrote:
> As implemented before r202131, all the code that checked for AlwaysInline
> also checked for ForceInline and treated it identically.
>
> This commit, r202131, does nothing to change the semantics of how clang
> feels about ForceInline.  It is just as correct or wrong as it was before.

Agreed. The difference is that previously, we had a choice for
splitting behaviors based on the semantic attribute, and now we have
to pay attention to the spelling were we to implement the documented
behaviors (which means we'd need to add accessors to the attr
declaration). It's not the end of the world at all, and given the
similarities between the semantics, I'm not *too* concerned by it. But
it's most definitely worth noting that __forceinline != always_inline
in terms of semantics, which somewhat suggests keeping the semantic
attributes separate.

> Quite frankly, many of the limitations that __forceinline is documented to
> have are ridiculous, it seems like their implementation is incredibly
> dependent on the frontend being able to do some analysis.

However, __forceinline is documented in MSDN, and always_inline is
documented for GNU (and neither are documented for Clang!). If we're
going to have the extension for compatibility with MSVC or GCC, we
should follow the documented behavior unless there's a good technical
reason to diverge. I make no claims as to whether there is or isn't a
reason to diverge here, but I would definitely say that divergence
should 1) be explicitly documented, 2) not be driven solely by what
the code currently does (or recently used to do), and 3) have some
public discussion that's not part of a post-commit review.

~Aaron