Hi all, TL;DR : If safer C++ static analyzer bot emits a false positive warning, try replacing the use of `auto` with the explicit type. It has been a while since we deployed the safer C++ static analyzer bot for WebKit. The safer C++ enforcement has been quite successful in reducing the total number of security bugs in the enforced code as we had anticipated. Thank you to many of you who have been fixing safer C++ warnings found in your PR. I wanted to give you one heads up that clang static analyzer can get easily confused by the use of `auto` keyword. Consider the following code: ensureWeakOnHTMLMediaElementContext([track = WTFMove(track), enabled](auto& mediaElement) mutable { auto audioTrack = AudioTrack::create(mediaElement.protectedScriptExecutionContext().get(), track); audioTrack->setEnabled(enabled); mediaElement.addAudioTrack(WTFMove(audioTrack)); }); The static analyzer was emitting a (false positive) warning for the first argument to `AudioTrack::create` even though `protectedScriptExecutionContext()` returns a `RefPtr`. This happens because the lambda function argument `mediaElement` uses `auto`. Because of this `auto`, static analyzer fails to determine the actual type of `mediaElement`. This in turn prevents the static analyzer from determining the return type of `protectedScriptExecutionContext()` and causes it to conclude that it may not be safe despite the fact it returns `RefPtr<ScriptExecutionContext>`. In this case, specifying the explicit type of the lambda argument eliminates this issue. So, next time safer C++ bot finds an obvious a false positive in your PR, try replacing `auto` by the explicit type. That might just eliminate the warning. - R. Niwa