Previously our repositories would build in either a Dev12 or a Dev14
Developer Command Prompt, but only if Dev12 (for MSBuild 12) was
on the box due to a hard-coded path to MSBuild 12. This change
will use MSBuild 14 if MSBuild 12 is not available. Also previously
this would look for MSBuild in the WOW Program Files path, this change
causes us to also look in the normal Program Files path for x86
Windows.
One of the disabled tests was obsolete. The design decision that was pending
is closed and the behavior tested did not match the decision. That test is
simply deleted.
The other test is changed from using [Fact(Skip="...")] to /*[Fact]*/. It is
now tracked by Issue #26.
Finally, I spotted a typo: 'overload' instead of 'overlong' nearby and fixed it.
If SecureObjectPool.NewId were to execute in a concurrent scenario where one thread actually was suspended while other threads were allowed to increment the counter enough to go through all 32-bits of values and the timing happened to be _just write_, we could theoretically return UnassignedId. This fixes it by looping until we get it right.
Enumerating some immutable collections are necessarily slower than ordinary collections because they have to walk binary trees. But we needn't throw in locks into the enumerator and slow it down further in an attempt to claim enumerators are somehow thread-safe. They're not. And misusing them across threads concurrently would already lead to corruption.
By removing the locks here, we've significantly improved performance of enumerating ImmutableSortedDictionary (and the other binary tree based collections). Even though the locks weren't contested, they still took a significant chunk of time.
The loss of the locking means that technically if the enumerator is in use across multiple threads then now it's possible for a recycled Stack to still be in use on another thread, leading to data corruption for the possibly innocent subsequent user of that stack. Since we've already decided that immutable collections will not be considered as behind a security boundary (i.e. we won't treat such possibilities as security compromising to the core system), this seems quite reasonable for such an unlikely and unsupported pattern to carry this risk given the huge wins it has for all the supported cases.
The Immutable PCL targets platforms that include those that don't support unsafe code. Opening the solution in VS2015 results in a warning in the error list about this. But features that required unsafe code were recently removed so we don't need this flag any more.
Avoid perf hit from acquiring a reusable stack object to enumerate a collection that is empty, and thus requires no stack object.
This improves ImmutableSortedDictionary directly, and both ImmutableDictionary and ImmutableHashSet benefit as well since they use ImmutableSortedDictionary internally.
In preparation for making our repositories public, I've uploaded
Microsoft.DotNet.BuildTools to NuGet.org. This change removes
our internal NuGet feed, leaving the public feed. With this change
the CoreFx repository should now build outside of Microsoft.
ImmutableArray.CreateBuilder<int>(-1); throws overflow exception but is expected to throw ArgumentOutOfRangeException.
Fix -
This fix checks the argument "capacity" for valid range such that ArgumentOutOfRangeException is thrown instead.
Also, added a testcase for this scenario.
Adam Ralph
Matt Cohn
dotnet-bot
Nick Guerrera
Eric Mellino
Andrew Arnott
stephentoub
Matt Ellis
Peter Marcu
Lakshmi Priya
richamsft