-
Notifications
You must be signed in to change notification settings - Fork 44
ParsingValidationTests failure in prodcon #93
Comments
@jonsequitur any clue? It should not be possible... everything is in memory |
When this runs in prodcon is it using the corefx/coreclr that was built before it? |
Another theory is the code uses == for assertion. But it is object equal. String interning could cause this problem. CliCommandLineParser/src/tests/CommandLine.Tests/ParsingValidationTests.cs Lines 62 to 72 in 1bae800
|
No, string overloads operator ==(a, b) to be the same as String.Equals(a, b) |
true, without any extra stuff and the type of e is string. public static bool operator ==(String a, String b)
{
return String.Equals(a, b);
} |
object obj = "String";
string str = typeof(string).Name;
Console.WriteLine($"{obj} == {str}?"); // --> String == String?
Console.WriteLine(obj == str); // --> False The question is why this would vary based on the build. We're guessing that changing the comparison from |
Interesting take. Treating that expression as object equals would be a bug in FluentAssertions. Seems like we should dig in, verify that, and report it to them if we can demonstrate that's indeed what's happening. |
It looks to me like FluentAssertions uses @tannergooding Repeating my question: Does prodcon execution of these tests use a just-built coreclr/corefx? |
@mmitche might be a better person to ask.
|
@mmitche No, it doesn't get a just-built copy, or no you're not the better person to ask? ;) |
@nguerrera It doesn't use a just-build coreclr/corefx |
The
When_no_option_accepts_arguments_but_one_is_supplied_then_an_error_is_returned
parsing validation test is failing in prodcon with:The test is not failing locally in any of the configurations I tested.
The text was updated successfully, but these errors were encountered: