Thanks to visit codestin.com
Credit goes to github.com

Skip to content

remove cxx03 test, fully unblocking c++1X development #1903

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

Merged
merged 21 commits into from
Feb 10, 2025
Merged

remove cxx03 test, fully unblocking c++1X development #1903

merged 21 commits into from
Feb 10, 2025

Conversation

dmah42
Copy link
Member

@dmah42 dmah42 commented Jan 13, 2025

removing cxx03_test allows us to use c++1X features in headers and thus clean up a bunch of clang-tidy warnings too.

after this i'll tackle the sanitizer and windows/clang32 CI bots.

@dmah42 dmah42 force-pushed the rmcxx03 branch 2 times, most recently from 96c291d to 4f85a1f Compare January 13, 2025 13:51
@dmah42 dmah42 marked this pull request as ready for review January 13, 2025 16:49
@dmah42 dmah42 requested a review from LebedevRI January 13, 2025 16:49
@dmah42
Copy link
Member Author

dmah42 commented Jan 24, 2025

@LebedevRI i'd appreciate your thoughts on taking this step. i think it's time, but i'm not entirely comfortable making the decision unilaterally.

@LebedevRI
Copy link
Collaborator

LebedevRI commented Feb 6, 2025

@LebedevRI i'd appreciate your thoughts on taking this step. i think it's time, but i'm not entirely comfortable making the decision unilaterally.

FWIW, i'm only now starting to actually look at github notifications, or read incoming mail.
Previous two/three years of mail (along with most github notifications),
especially over last 3+ months, went into trash.

Copy link
Collaborator

@LebedevRI LebedevRI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please drop the enum changes (outside of test/) from this PR, i.e., do explicitly specify the underlying type, which i guess is int, and do the type narrowing in a follow-up PR?
Latter may or may not have ABI implications and should be more explicit.
https://godbolt.org/z/d46eGcsoj

@dmah42
Copy link
Member Author

dmah42 commented Feb 7, 2025

i'm happy to, but how would we test the ABI implications in that other PR? i'm not seeing how splitting it is going to make it any safer, unless you just want something to more easily roll back?

@dmah42
Copy link
Member Author

dmah42 commented Feb 7, 2025

done

@LebedevRI
Copy link
Collaborator

i'm happy to, but how would we test the ABI implications in that other PR? i'm not seeing how splitting it is going to make it any safer, unless you just want something to more easily roll back?

Without that change, this PR is rather no-changes-intended and is easy to review.
When that change is on it's own, it will at least be more explicit that it's what is going on,
maybe we'll do the enum narrowing maybe we won't.

@dmah42
Copy link
Member Author

dmah42 commented Feb 7, 2025

well, we will do it, because the whole point is to get clang-tidy to stop complaining :)

@@ -84,7 +84,7 @@
namespace benchmark {
namespace {

void PrintImp(std::ostream& out) { out << std::endl; }
void PrintImp(std::ostream& out) { out << '\n'; }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we flush stream[s] before calling std::exit(), since it does not do that automatically?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

adding to everywhere we explicitly exit

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's probably other places where we might flush intentionally, but this is better than nothing.

@@ -544,8 +506,7 @@ inline BENCHMARK_ALWAYS_INLINE void DoNotOptimize(Tp&& value) {
asm volatile("" : "+m,r"(value) : : "memory");
#endif
}
#endif
#elif defined(BENCHMARK_HAS_CXX11) && (__GNUC__ >= 5)
#elif (__GNUC__ >= 5)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This needs a comment. It took me a while to get that it is for #if !defined(__GNUC__) || defined(__llvm__) || defined(__INTEL_COMPILER)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it took me ages to navigate these ifdefs too. added comments.

Comment on lines 493 to 494
std::cerr << "Failed to create unique temporary file name\n";
std::abort();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(Abort is same as exit)

@@ -57,7 +57,7 @@ class CheckHandler {
#pragma warning(disable : 4722)
#endif
BENCHMARK_NORETURN ~CheckHandler() BENCHMARK_NOEXCEPT_OP(false) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this/CallAbortHandler flush?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice.. we have too many exit points :P

LebedevRI
LebedevRI previously approved these changes Feb 10, 2025
Copy link
Collaborator

@LebedevRI LebedevRI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And github ate my comment.

I really don't like this flush mess.
I think we should just never use std::endl,
always use \n, and explicitly flush the nessesary streams when needed.

Otherwise this seems fine to me, thank you for doing this!

@dmah42
Copy link
Member Author

dmah42 commented Feb 10, 2025

sorry @LebedevRI i wiped your approval by merging and adding more flushes.

@LebedevRI
Copy link
Collaborator

sorry @LebedevRI i wiped your approval by merging and adding more flushes.

(No, it literally ate a whole comment. Maybe it happened to get posted the moment you pushed.)

@dmah42 dmah42 merged commit 835365f into main Feb 10, 2025
95 of 101 checks passed
@dmah42 dmah42 deleted the rmcxx03 branch February 10, 2025 22:17
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.

2 participants