Hashset.TrimExcess(int capacity) corrupts hashset data structure

[weltkante]

Description

HashSet.TrimExcess (introduced in #66426 for .NET 9) sets Count=Capacity even if it doesn't have as many items. The excess items are default initialized, including the internal state the HashSet uses (hashcode and freelist links). This corrupts the hashset data structure as iterating will yield the uninitialized items but direct lookup will not see them.

Reproduction Steps

var Set = new HashSet<int>(200);
for (int i = 50; i < 60; i++)
    Set.Add(i);

Console.WriteLine($"Set.Count = {Set.Count}");
Console.WriteLine($"Set.TrimExcess(20)");
Set.TrimExcess(20);

Console.WriteLine($"Set.Count = {Set.Count}");
Console.WriteLine($"Set.ToArray().Length = {Set.ToArray().Length}");
Console.WriteLine($"foreach (var item in set)");
foreach (var item in Set)
    Console.WriteLine($"  Set.Contains({item}) = {Set.Contains(item)}");

Expected behavior

Count remains as before the trimming.

Actual behavior

Count is increased to full capacity

Regression?

no, new API

Known Workarounds

don't use the method with a capacity > count (making the new API rather useless)

Configuration

.NET 9.0.0-preview.2.24080.1

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-collections
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

HashSet.TrimExcess (introduced in #66426 for .NET 9) sets Count=Capacity even if it doesn't have as many items. The excess items are default initialized, including the internal state the HashSet uses (hashcode and freelist links). This corrupts the hashset data structure as iterating will yield the uninitialized items but direct lookup will not see them.

Reproduction Steps

var Set = new HashSet<int>(200);
for (int i = 50; i < 60; i++)
    Set.Add(i);

Console.WriteLine($"Set.Count = {Set.Count}");
Console.WriteLine($"Set.TrimExcess(20)");
Set.TrimExcess(20);

Console.WriteLine($"Set.Count = {Set.Count}");
Console.WriteLine($"Set.ToArray().Length = {Set.ToArray().Length}");
Console.WriteLine($"foreach (var item in set)");
foreach (var item in Set)
    Console.WriteLine($"  Set.Contains({item}) = {Set.Contains(item)}");

Expected behavior

Count remains as before the trimming.

Actual behavior

Count is increased to full capacity

Regression?

no, new API

Known Workarounds

don't use the method with a capacity > count (making the new API rather useless)

Configuration

.NET 9.0.0-preview.2.24080.1

Other information

No response

Author:	weltkante
Assignees:	-
Labels:	area-System.Collections, untriaged
Milestone:	-

[stephentoub]

TrimExcess shouldn't be setting the count at all.

[weltkante]

TrimExcess shouldn't be setting the count at all.

Count is not stored as immediate value but as difference between free/used slots, those numbers change during the trimming so have to be reassigned, even though the difference ought to remain the same. Assigning capacity instead of count is a bug in the original code (not part of the PR introducing the API) and never surfaced before because previously it only was called with capacity==count, only the new API allows calling it with different values. I'm surprised this didn't surface in unit tests of the new API though, since setting capacity != count is the whole point of it.