lerp() noexcept is now required, so we should remove comments#640
lerp() noexcept is now required, so we should remove comments#640cbezault merged 3 commits intomicrosoft:masterfrom
Conversation
StephanTLavavej
left a comment
There was a problem hiding this comment.
Thanks for taking care of this! Perhaps surprisingly, removing these comments is causing our pull request checks to fail. That's because we run clang-format on the STL's product and test code (making it easy to have consistently formatted code without a lot of human review and intervention), and our checks verify that clang-format doesn't want to change any files.
In this case, the /* strengthened */ comments were causing clang-format to wrap long lines; we have a column limit of 120 here:
Line 85 in 02043f8
By removing the comments, some of these lines now fit in 120 columns, so clang-format wants to unwrap them.
You can fix this by running clang-format 9 on this file (Clang 10 was just released, with different clang-format behavior; we'll be updating to that soon but not yet). This would be important for large-scale changes, or future pull requests. Alternatively, a quick way to fix this PR is to look at the failing checks, which we've configured to print the changes that clang-format wants to make, and just manually unwrap the affected lines. We run clang-format as part of the x64 build, so you can click on the "Details" next to the "microsoft.STL (x64)" checks at the bottom of the PR; that will take you to https://github.com/microsoft/STL/pull/640/checks?check_run_id=535466270 which shows that the float and double overloads should be unwrapped. (Alas, long double is verbose enough to still require wrapping.)
You can even configure your editor to automatically run clang-format; if you use VSCode with Microsoft's C/C++ Extension, then opening the repo's folder will pick up our "format on save" setting:
Line 5 in 02043f8
Who would have expected that removing 3 comments could be so complicated? 😹
|
Thanks for the very detailed comment! In this kind of case, do you prefer amending/force pushing the commit, or adding a new commit with the fixed formatting? |
|
Thanks for asking! Adding a new commit makes reviewing easier, since GitHub provides UI to see "changes since your last review". When we merge pull requests, we choose to squash each PR into a single commit for tidy linear history, so it won't affect what goes into the repo history. |
|
Thanks! Should I run clang-format 10.0 from now on? |
Yes - clang-format 10 is now the gold standard. |
|
Thanks for the contribution! |
Description
Remove
/* strengthened*/comments now thatnoexceptis required by the standard.Fixes #530
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.
_Uglyas 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 (including any cited standards), other WG21 papers
(excluding reference implementations outside of proposed standard wording),
and LWG issues as reference material. 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.