I think this is actually a true positive bug that could lead to crashes in production if the table is resized during pruning. We don't seem to have coverage of these tests in this configuration on the CQ, so nobody noticed.

This is the code in question:

  scoped_refptr<SimpleFontData>& font_data =
      font_data_table_.insert(key, nullptr).stored_value->value;
  if (!font_data)
    font_data = CreateFontData(font_description, font_selection_capabilities);

  font_cache_key_age.PrependOrMoveToFirst(key);
  PruneOldestIfNeeded(); // modifies font_data_table_

wtf::HashTable has a pretty neat DCHECK to protect against dangling iterators pointing into the table after modification. The result of the '.insert()' call is such an iterator. MSVC lifetime extends it to the entire scope, but clang does not.

If the iterator is lifetime extended, it gets destroyed *after* the PruneOldestIfNeeded() call, and it always asserts in DCHECK-enabled build modes. You can reproduce the issue with clang if you rewrite the code like so:

  // tmp will live until after pruning and assert during cleanup
  auto tmp = font_data_table_.insert(key, nullptr);
  scoped_refptr<SimpleFontData>& font_data = tmp.stored_value->value;

|font_data| is a reference into the table, so if the table is rehashed, it will dangle. We should copy the scoped_refptr earlier and let NRVO elide the copy that would normally take place in the return. I'll put together a CL.