Bug 190819 – Cleanup: inline constexpr is redundant as constexpr implies inline

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Daniel Bates]

As per [dcl.constexpr] (2), "constexpr functions and constexpr constructors are implicitly inline" (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3797.pdf). So, it is sufficient to annotate a function with "constexpr" instead of annotating with "inline constexpr".

[Daniel Bates]

Bonus points: teach the style checker to recognize "inline constexpr" and provide an informative diagnostic message that suggests using dropping the "inline" keyword.

[Ross Kirsling]

(In reply to Daniel Bates from comment #1)
> Bonus points: teach the style checker to recognize "inline constexpr" and
> provide an informative diagnostic message that suggests using dropping the
> "inline" keyword.

Looks like clang-tidy should support this in the future:
https://reviews.llvm.org/D18914

[Ross Kirsling]

(In reply to Ross Kirsling from comment #2)
> (In reply to Daniel Bates from comment #1)
> > Bonus points: teach the style checker to recognize "inline constexpr" and
> > provide an informative diagnostic message that suggests using dropping the
> > "inline" keyword.
> 
> Looks like clang-tidy should support this in the future:
> https://reviews.llvm.org/D18914

Er hmm, I posted that before double-checking the date. Guess it's kind of stale. 😓

[Ross Kirsling]

Created attachment 353108 [details]
Patch

[Mark Lam]

Comment on attachment 353108 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=353108&action=review

> Source/JavaScriptCore/ChangeLog:3
> +        Cleanup: inline constexpr is redundant as constexpr implies inline

Are you sure that this is true?  constexpr functions may be called on none const arguments, and therefore produce a non-constexpr value.  Marking a function constexpr only means that it *can* produce a constexpr value, not necessarily that it *will* produce a constexpr value.  Hence, I'm not sure that constexpr necessarily means the function will be inlined.  At least that's my understanding.  Am I wrong?

[Ross Kirsling]

(In reply to Mark Lam from comment #5)
> Comment on attachment 353108 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=353108&action=review
> 
> > Source/JavaScriptCore/ChangeLog:3
> > +        Cleanup: inline constexpr is redundant as constexpr implies inline
> 
> Are you sure that this is true?  constexpr functions may be called on none
> const arguments, and therefore produce a non-constexpr value.  Marking a
> function constexpr only means that it *can* produce a constexpr value, not
> necessarily that it *will* produce a constexpr value.  Hence, I'm not sure
> that constexpr necessarily means the function will be inlined.  At least
> that's my understanding.  Am I wrong?

According to https://en.cppreference.com/w/cpp/language/constexpr:
> A constexpr specifier used in a function ... declaration implies inline.

So that's seems pretty unambiguous... But of course, we wouldn't want to touch any ALWAYS_INLINE cases.

[Mark Lam]

Comment on attachment 353108 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=353108&action=review

r=me

>>> Source/JavaScriptCore/ChangeLog:3
>>> +        Cleanup: inline constexpr is redundant as constexpr implies inline
>> 
>> Are you sure that this is true?  constexpr functions may be called on none const arguments, and therefore produce a non-constexpr value.  Marking a function constexpr only means that it *can* produce a constexpr value, not necessarily that it *will* produce a constexpr value.  Hence, I'm not sure that constexpr necessarily means the function will be inlined.  At least that's my understanding.  Am I wrong?
> 
> According to https://en.cppreference.com/w/cpp/language/constexpr:

Excellent.

[WebKit Commit Bot]

Comment on attachment 353108 [details]
Patch

Clearing flags on attachment: 353108

Committed r237429: <https://trac.webkit.org/changeset/237429>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/45569008>