Skip to content
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

Merged
merged 5 commits into from
Nov 5, 2019

Conversation

SuperWig
Copy link
Contributor

@SuperWig SuperWig commented Nov 3, 2019

Description

Hopefully resolves #250 as it seemed like you were all in agreement.

  • Used the phrase "The contents of <meow> are only available available only with C++meow or later."
  • Changed the #else comments to use the name of the macro
  • Inverted the condition so the message is at the top of the file.
  • Removed a newline in <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.

  • Identifiers in product code changes are properly _Ugly as per
    https://eel.is/c++draft/lex.name#3.1 or there are no product code changes.
  • The STL builds successfully and all tests have passed (must be manually
    verified by an STL maintainer before automated testing is enabled on GitHub,
    leave this unchecked for initial submission).
  • These changes introduce no known ABI breaks (adding members, renaming
    members, adding virtual functions, changing whether a type is an aggregate
    or trivially copyable, etc.).
  • These changes were written from scratch using only this repository and
    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.

@SuperWig SuperWig requested a review from a team as a code owner November 3, 2019 11:30
stl/inc/any Outdated Show resolved Hide resolved
stl/inc/concepts Outdated Show resolved Hide resolved
stl/inc/ranges Outdated Show resolved Hide resolved
stl/inc/concepts Outdated Show resolved Hide resolved
@@ -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
Copy link
Contributor Author

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)?

Copy link
Member

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).)

Copy link
Contributor Author

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?

Copy link
Member

@StephanTLavavej StephanTLavavej left a 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
Copy link
Member

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).)

@StephanTLavavej
Copy link
Member

Note that when merged, #133, #142, and #223 will all need to follow this pattern.

@StephanTLavavej
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@StephanTLavavej
Copy link
Member

<execution> and <variant> are failing the clang-format step (possibly due to trailing whitespace? clang-format validation runs before the whitespace checker.)

@BillyONeal
Copy link
Member

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?

@SuperWig
Copy link
Contributor Author

SuperWig commented Nov 4, 2019

They seem to be in places unrelated to this PR 😕

@StephanTLavavej
Copy link
Member

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@StephanTLavavej
Copy link
Member

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.)

@StephanTLavavej
Copy link
Member

I wish I knew how to make the PR bot just fix it rather than complaining.

I don't believe that's supported.

I could do 'git diff' rather than 'git status' to print out differences though?

I created #255 for this.

@@ -9,7 +9,9 @@
#include <yvals_core.h>
#if _STL_COMPILER_PREPROCESSOR

#if _HAS_CXX17
#if !_HAS_CXX17
Copy link
Member

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!

@miscco miscco mentioned this pull request Nov 5, 2019
7 tasks
@StephanTLavavej StephanTLavavej merged commit 9d635aa into microsoft:master Nov 5, 2019
@StephanTLavavej
Copy link
Member

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).

@SuperWig SuperWig deleted the mode branch November 6, 2019 16:04
@miscco miscco mentioned this pull request Nov 20, 2019
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

STL: Consider consistently rephrasing Standard mode diagnostics
5 participants