I think that http://llvm.org/viewvc/llvm-project?view=revision&revision=342605 exposed a problem in net/third_party/quic/platform/impl/quic_mutex_impl.h where QuickLockImpl is *not* annotated as LOCKABLE:

    // A class wrapping a non-reentrant mutex.
    class QUIC_EXPORT_PRIVATE QuicLockImpl { <- *** no LOCKABLE annotation on the class itself ***
     public:
      QuicLockImpl() = default;
    
      // Block until lock_ is free, then acquire it exclusively.
      void WriterLock() EXCLUSIVE_LOCK_FUNCTION();
    
      // Release lock_. Caller must hold it exclusively.
      void WriterUnlock() UNLOCK_FUNCTION();
    
      // Block until lock_ is free or shared, then acquire a share of it.
      void ReaderLock() SHARED_LOCK_FUNCTION();
    
      // Release lock_. Caller could hold it in shared mode.
      void ReaderUnlock() UNLOCK_FUNCTION();
    
      // Not implemented.
      void AssertReaderHeld() const ASSERT_SHARED_LOCK() {}
    
     private:
      base::Lock lock_;
    
      DISALLOW_COPY_AND_ASSIGN(QuicLockImpl);
    };

Of course none of compile errors would have happened if //base/thread_annotations.h wasn't (transitively) included when processing net/third_party/quic/platform/impl/quic_mutex_impl.h (it gets transitively included because of r591776).

Internal CL with the fix uploaded here: cr/213856457.  Let's discuss there (including whether a separate Chromium CL is needed, or if we can just wait for the regular/periodic quic roll).

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb0dd07017538e2bcbb0b649c6e407816b3bd69a

commit eb0dd07017538e2bcbb0b649c6e407816b3bd69a
Author: Lukasz Anforowicz <lukasza@chromium.org>
Date: Fri Sep 21 17:18:30 2018

Add LOCKABLE annotation to QuicLockImpl.

QuicLockImpl's methods had various lock annotations (e.g.
EXCLUSIVE_LOCK_FUNCTION), but the class itself wasn't annotated as
LOCKABLE.  After a recent clang change this was causing compiler errors
like the one reported in  https://crbug.com/887610 .

This CL fixes this by adding LOCKABLE annotation to QuicLockImpl.

I've searched for other files under //net/third_party/quic that include
LOCK_FUNCTION substring but do not include LOCKABLE substring.  It seems
that quic_mutex_impl.h was the only one.

Merge internal change 213866214

Bug:  887610 
Change-Id: Iddedd166a97cfe1f77ea2c14a6e98a836bdb08d8
Reviewed-on: https://chromium-review.googlesource.com/1237716
Reviewed-by: Zhongyi Shi <zhongyi@chromium.org>
Commit-Queue: Zhongyi Shi <zhongyi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593240}
[modify] https://crrev.com/eb0dd07017538e2bcbb0b649c6e407816b3bd69a/net/third_party/quic/platform/impl/quic_mutex_impl.h

https://luci-milo.appspot.com/buildbot/chromium.clang/ToTLinux/3742 is the first build to include the fix from #c3 / r593240, but unfortunately it seems that another build error has creeped in in the meantime - even https://luci-milo.appspot.com/buildbot/chromium.clang/ToTLinux/3741 hits the other error (before even getting to the error being covered by the current bug).

Given above, I think I will (speculatively) mark the current bug as fixed, and use another separate bug ( issue 888061 ) for the other problem.