The change to SBDebugger::GetProgressFromEvent needs to be removed.

It failed because on macOS, the underlying args contains argv0 while on Linux it does not. So my test that checked that GetNumArguments is 1 fails on macOS, since there are 2.

Not sure why this failed. Is it perhaps a difference where some processes have args including the executable and some do not?

Rebase and address feedback.

I had requested it and got it a short bit ago. Looks like I landed it successfully. Thanks for the review!

Mark as NFC.

Remove incorrect change.

Should this include something for disabling as well?

In addition to my previous explanation for the concerns about using nullptr more ... it should be noted that many of these files already use nullptr.

Updating to current master.

I'd modified CMakeLists.txt to add -Wdouble-promotion and removed this line: -Wno-double-promotion # FIXME: remove me ...

In D43159#1526215, @mclow.lists wrote:

What was the result of testing with -std=c++98 and/or -std=gnu++98 ?
The code changes look fine; but as @EricWF said....

More nullptr-ification.

Remove CMakeLists.txt change.

Updated to current master and added more nullptr usage.

Can we revive this review? I'd still like to land it ...

Can we revive this review? I'd still like to land this ...

This sounds great to me.

I recognize that it might be dull, but should you re-sort the various include lists so that the now-in-Utility headers are listed with the other Utility headers?

I can land this today.

A couple of additional fixes.

Without this, anyone using clang-tidy with this check gets 6 system header warnings whenever they transitively have included limits.

This is modernize-redundant-void-arg: https://clang.llvm.org/extra/clang-tidy/checks/modernize-redundant-void-arg.html

Rebased forward.

In D43159#1004617, @jroelofs wrote:

Is it worth adding -Werror=zero-as-null-pointer-constant to the build?

In D43159#1004639, @dim wrote:

In D43159#1004625, @EricWF wrote:

So my main concern with this patch is that nullptr is actually #defined'ed in C++03 mode. That definition comes from the __nullptr header, and therefore we would need to add that header to each include which uses it. Which kind of sucks.

Indeed, but isn't nullptr used in many headers already? And as far as I can see, none of those includes <__nullptr> explicitly, so the definition must come from some transitive include.

Addressed minor issues.

More nullptr usage.

Update per comments.

Pavel, since Jim was okay with this before apart from it not having a test, want to take a quick look now? Thanks!

Add a test.

This was accepted long ago, and then I got sidetracked for a while. Is this still okay to land?