ModifyCollectionInEnhancedForLoop is triggered for ConcurrentMap

[ejona86]

Description of the problem / feature request:

ModifyCollectionInEnhancedForLoop is triggered for ConcurrentMap. While this could be on purpose, as technically ConcurrentHashMap defines the no-throw-ConcurrentModificationException policy, it seems this is accidental in some way as ConcurrentMap is part of java.util.concurrent which is skipped by the check.

Bugs: what's the simplest, easiest way to reproduce this bug?

We have the code:

  private final ConcurrentMap<Locality, ClientLoadCounter> localityLoadCounters;
...
    for (Map.Entry<Locality, ClientLoadCounter> entry : localityLoadCounters.entrySet()) {
        ...
        localityLoadCounters.remove(entry.getKey());

Which causes a ModifyCollectionInEnhancedForLoop warning:

grpc-java/xds/src/main/java/io/grpc/xds/LoadStatsStoreImpl.java:94: warning: [ModifyCollectionInEnhancedForLoop] Modifying a collection while iterating over it in a loop may cause a ConcurrentModificationException to be thrown or lead to undefined behavior.
        localityLoadCounters.remove(entry.getKey());
                                   ^
    (see https://errorprone.info/bugpattern/ModifyCollectionInEnhancedForLoop)

Swapping from ConcurrentMap to ConcurrentHashMap silences the warning.

Looking at the code, there does not seem to be any ConcurrentMap vs ConcurrentHashMap special-casing, just a large special-case for java.util.concurrent:

error-prone/core/src/main/java/com/google/errorprone/bugpatterns/ModifyCollectionInEnhancedForLoop.java

Lines 76 to 85 in 55a5956

	if (state.getTypes().closure(ASTHelpers.getSymbol(tree).enclClass().asType()).stream()
	.anyMatch(
	s ->
	s.asElement()
	.packge()
	.getQualifiedName()
	.toString()
	.startsWith("java.util.concurrent"))) {
	return NO_MATCH;
	}

It's unclear how ConcurrentMap triggers the warning.

What version of Error Prone are you using?

2.4.0

Have you found anything relevant by searching the web?

No.