[compiler-rt] [asan] Fix asan_new_delete.cpp C++ header resolution under -nostdinc++ (PR #202816)

[Justin T. Gibbs via llvm-commits]

scsiguy wrote:

> > > @scsiguy Since you already have this fix-forward ready, I've requested the reviews. But for future reference: "we tend to make much heavier use of reverts to keep the tree healthy than some other open source projects, and our norms are a bit different …
> > 
> > 
> > @thurstond, thanks for the feedback. I don’t think the guidance here is that different from other projects I’ve worked on (e.g. FreeBSD), and this was also my first inclination. However, the failure is in the CI of a downstream project (Fuscia) and a fix for their immediate issue had already been merged - preventing a clean revert - so fixing forward seemed the right approach. Should I have just reverted both commits?
> 
> It's a grey area but personally I would have erred on the side of reverting both commits, because:
> 
> 1. this fix-forward is non-trivial. Reverting both commits is easy to author and review [*], and would bring the bots back to green quicker.

I'm struggling to understand how this scenario applies here. The reported breakage was not observable in the context of the llvm build bots. (This implies there is some coverage gap there.) But maybe you mean this approach should apply for any reported defect on a recent change?

> 2. reverting both commits is indeed an inconvenience, but then, if there are still lingering issues after this fix-forward, it'd be a stack of three commits, which would be even more inconvenient to revert ...
> 
> [*] if you had commit access, the review would not even be needed: "You are allowed to commit patches without approval which you think are obvious. This is clearly a subjective decision — we simply expect you to use good judgement. Examples include: fixing build breakage, reverting obviously broken patches, documentation/comment changes, any other minor changes."

I guess this is another reason for me to apply for commit access. It's unfortunate that this is the best path for even occasional contributors. I feel like most of what I need to reduce workflow friction is just the ability to request reviews and revert my own merged change. I recognize the later wouldn't quite work here because a conflicting commit was already merged, but maybe they too would have just hit the "revert this" button if that were available and known to be reliable.



https://github.com/llvm/llvm-project/pull/202816