ScopedUnlock isn't supported by the annotation tool, but annotating the other things should get us pretty far.

Easy way to see what's broken:
git cl patch https://chromium-review.googlesource.com/#/c/chromium/src/+/1008731
update gn args to set treat_warnings_as_errors to false.
build

On a related note, annotating ScopedUnlock is blocked on https://bugs.llvm.org/show_bug.cgi?id=36162. Mentioning it here because the bug reference is currently buried deep in a chromium-dev thread.

@dcheng: don't we need to support ScopedUnlock first? Otherwise we'll end up with a bunch of false positive warnings?

I tried building today and I "only" got a few hundred lines of warnings or so. So maybe it won't be that bad? I was thinking of just suppressing those warnings for now.

Also, AutoUnlock is rarer, relatively speaking, so I think it ought to be OK.

How do suppressions work? I agree that AutoUnlock is rare but it also shouldn't be a pain to add one to a lock that is already widely used without one (i.e. ok if warning is local, annoying if warning spreads to all existing usages of that Lock).

In any case, a hundred warnings, ouch! I'm not that surprised but I would have ballparked ≈30, not hundreds! Also enabling these annotations allows us to get rid of crazy things I did in the past to lock in fixes to locking paradigms (e.g. safe_browsing::DatabaseStateManager::ThreadSafeStateManager)..!

I think NO_THREAD_SAFETY_ANALYSIS should suppress analysis in the scope where AutoUnlock is used--though we'd probably want to label it something AutoUnlock specific to make it easy to cleanup later.

 Issue 881903  has been merged into this issue.

For a smaller, easier first step see issue 881875.