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".
Bonus points: teach the style checker to recognize "inline constexpr" and provide an informative diagnostic message that suggests using dropping the "inline" keyword.
(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
(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. 😓
Created attachment 353108 [details] Patch
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?
(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.
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.
Comment on attachment 353108 [details] Patch Clearing flags on attachment: 353108 Committed r237429: <https://trac.webkit.org/changeset/237429>
All reviewed patches have been landed. Closing bug.
<rdar://problem/45569008>