In D150298#4354481, @fmayer wrote:

In D150298#4354471, @yln wrote:

In D150298#4354287, @fmayer wrote:

Apart from my other comment, if you want to go ahead I would suggest implementing this in a different way and only removing the MaybeBuildIdToBuffer from the implementation of 'L' in sanitizer_stacktrace_printer.cpp, then a) people can still manually get the build id if their format string uses %b, and b) the MaybeBuildIdToBuffer function doesn't unnecessarily not work on OS X, which is confusing.

I think these are good suggestions. How about combining this with Vitaly's suggestion for using a flag to only change this on Apple platforms (and to enable everyone to still get the current output)?

Just thought of an even more flexible approach. Make the frame format string a configuration option, so we can specify platform-dependent defaults, allow users to get current behavior (on Apple platforms), and give them the ability to fully customize if they desire.

static const char kDefaultFormat[] = "    #%n %p %F %L";

@vitalybuka @fmayer
What do you think?

The custom strings would involve splitting the %b from the %L and putting "%L %b" as the custom string, which would lead to an extraneous space if %b is empty. We could add the space as the first character of the %b, but that's kind of ugly.

In D150298#4354170, @fmayer wrote:

Can you please elaborate in the change description why "On Darwin, we do not want to show the BuildId appended at the end of stack
frames in Sanitizers."?

There is no change in UBSan.

Feedback fixes

There are two more calls to MaybeBuildIdToBuffer in the switch statement. I did not guard them with !SANITIZER_APPLE because they do not affect the codepath on Darwin. If we want, I can also guard them with !SANITIZER_APPLE, or just guard the function implementation itself rather than the call sites.

This test is failing on ios arm64e. It seems like the function is not getting overridden on ios.

use filter instead of remove

I have reverted the commit for now

@dmaclach Can you please take a look and fix this? Thanks

I was verifying that static versions of these libraries are not present on darwin. Sorry for the delay.

Sorry for this. I need to confirm that asan and tsan are not supported on darwin. Please don't merge until then. Thanks

LGTM

minor refactoring

fix typo

minor typo fix in comments

Minor bugfix

The libcxx test failure seems unrelated and seems to be failing on master
https://buildkite.com/llvm-project/libcxx-ci/builds?branch=master

Removing unnecessary code from test

Closed by 4729f6e03a12b0f3613416dc6f65407afa7e8f19

Addressing comments

LGTM

Added a minor comment below. Apart from that looks good to me

Fix commit message

• updated canResolveToExpr to accept both statements and expressions. Removed unnecessary code

Updating patch

Added a separate check for unevaluated statements. Updated InfiniteLoopCheck to use new check

Fixed clang-format issue

Updated tests