-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Account for possible cache invalidation on a different thread in assert. #59635
Conversation
@@ -1169,7 +1169,9 @@ public INamedTypeSymbol CreateNativeIntegerTypeSymbol(bool signed) | |||
{ | |||
val = CommonGetTypeByMetadataName(fullyQualifiedMetadataName); | |||
var result = _getTypeCache.TryAdd(fullyQualifiedMetadataName, val); | |||
Debug.Assert(result || (_getTypeCache.TryGetValue(fullyQualifiedMetadataName, out var addedType) && ReferenceEquals(addedType, val))); | |||
Debug.Assert(result | |||
|| !_getTypeCache.TryGetValue(fullyQualifiedMetadataName, out var addedType) // Could fail if the type was already evicted from the cache |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if we add a type we should always get the same instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if we add a type we should always get the same instance?
I believe it should always be the same instance. This API effectively just walks through every assembly and looks for the member symbols from the assembly, and (in C#) gets the public version. Those should not be changing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (commit 1)
@dotnet/roslyn-compiler For the second review. |
@dotnet/roslyn-compiler for a second review please. |
Attempt at fixing #59395. Reviewing the codepath I don't see any other obvious points that could cause the assert to fail, so if it continues to reproduce after this change we can look at further logging to determine the root cause.