-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use consistent phrasing of required standard mode #252
Conversation
@@ -34,8 +36,6 @@ _STD_END | |||
_STL_RESTORE_CLANG_WARNINGS | |||
#pragma warning(pop) | |||
#pragma pack(pop) | |||
#else // ^^^ Concepts support / no Concepts vvv | |||
#pragma message("The contents of <ranges> are only available with C++20 concepts support.") | |||
#endif // __cpp_lib_concepts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these be defined(__cpp_lib_concepts)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. Our current practice is inconsistent (because we've added arrow comments over the years). Your PR currently follows one of our patterns - repeating the macro name as the #endif
comment, despite the arrow comment on the #else
. So this would be fine to leave as-is. You could also consistently use a matching arrow, which would be // ^^^ defined(__cpp_lib_concepts) ^^^
here. (The one thing we don't do is pair #ifndef MEOW
with #endif // defined(MEOW)
.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I assume they would eventually be replaced with _HAS_CXX20
at some point. So I guess It would eventually solve itself?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these changes are great. I'm inclined to merge them as-is, and if we want to make our preprocessor comments more consistent, do that in a separate PR.
@@ -34,8 +36,6 @@ _STD_END | |||
_STL_RESTORE_CLANG_WARNINGS | |||
#pragma warning(pop) | |||
#pragma pack(pop) | |||
#else // ^^^ Concepts support / no Concepts vvv | |||
#pragma message("The contents of <ranges> are only available with C++20 concepts support.") | |||
#endif // __cpp_lib_concepts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. Our current practice is inconsistent (because we've added arrow comments over the years). Your PR currently follows one of our patterns - repeating the macro name as the #endif
comment, despite the arrow comment on the #else
. So this would be fine to leave as-is. You could also consistently use a matching arrow, which would be // ^^^ defined(__cpp_lib_concepts) ^^^
here. (The one thing we don't do is pair #ifndef MEOW
with #endif // defined(MEOW)
.)
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
|
I wish I knew how to make the PR bot just fix it rather than complaining. I could do 'git diff' rather than 'git status' to print out differences though? |
They seem to be in places unrelated to this PR 😕 |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
I believe clang-format's behavior is affected by the phrasing of preprocessor conditionals, so it decided to format different branches. (I don't understand its criteria yet.) |
I don't believe that's supported.
I created #255 for this. |
@@ -9,7 +9,9 @@ | |||
#include <yvals_core.h> | |||
#if _STL_COMPILER_PREPROCESSOR | |||
|
|||
#if _HAS_CXX17 | |||
#if !_HAS_CXX17 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am usually the person who hates inverted conditionals with else, but I think this is the exception that proves the rule :) Thanks!
Thanks for the improvement! Hopefully this will help some users understand why they're getting these diagnostics (especially with the message now at the top of each header). |
Description
Hopefully resolves #250 as it seemed like you were all in agreement.
<meow>
areonly availableavailable only with C++meow or later."#else
comments to use the name of the macro<variant>
as none of the other headers had one there.Checklist
Be sure you've read README.md and understand the scope of this repo.
If you're unsure about a box, leave it unchecked. A maintainer will help you.
_Ugly
as perhttps://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
verified by an STL maintainer before automated testing is enabled on GitHub,
leave this unchecked for initial submission).
members, adding virtual functions, changing whether a type is an aggregate
or trivially copyable, etc.).
the C++ Working Draft as a reference (and any other cited standards).
If they were derived from a project that's already listed in NOTICE.txt,
that's fine, but please mention it. If they were derived from any other
project (including Boost and libc++, which are not yet listed in
NOTICE.txt), you must mention it here, so we can determine whether the
license is compatible and what else needs to be done.