In #82450 we added IsEnglishLocal to some tests. What we found is that some tests are using CodeAnalysisResource strings in their diagnostic verification:
- MissingIteratorStateMachineAttribute
- BadIteratorStateMachineAttribute
- SourceAsyncStateMachineAttribute
- NonIteratorToIterator_MissingAttribute
Others do not and have been marked with IsEnglishLocal:
- MissingAsyncStateMachineAttribute
- AddedAsyncStateMachineAttribute
- NonAsyncToAsync_MissingAttribute
Need to determine whether TestBase is doing the right thing
|
// Force the UI culture to be the same as current culture. This will more fully exercise our |
|
// localization paths on machines that aren't en-US. |
|
// |
|
// Consider as an example our test infrastructure which runs machines in the es-ES locale. The |
|
// machine setup is such that CurrentCulture is es-ES but CurrentUICUlture is en-US. That means |
|
// our test infra isn't actually testing anything with respect to resource strings as they |
|
// all load with CurrentUICulture. This normalization means that when running on a machine |
|
// that doesn't use en-US we fully test our capabilities here. |
|
if (CultureInfo.CurrentUICulture != CultureInfo.CurrentCulture) |
|
{ |
|
_originalUICulture = CultureInfo.CurrentUICulture; |
|
CultureInfo.CurrentUICulture = CultureInfo.CurrentCulture; |
|
} |
In #82450 we added IsEnglishLocal to some tests. What we found is that some tests are using CodeAnalysisResource strings in their diagnostic verification:
Others do not and have been marked with
IsEnglishLocal:Need to determine whether TestBase is doing the right thing
roslyn/src/Compilers/Test/Core/TestBase.cs
Lines 30 to 42 in 6fc483d