-
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
Incorrect result is produced by DataFlowAnalysis.DataFlowsOut when local functions are involved #41600
Comments
@AbhitejJohn @nohwnd @cvpoienaru looks like testhost process is crashing for above Roslyn unit test when the test fails. Is this expected behavior for testhost? Or is this likely to be something related to how the unit tests themselves are configured / some problem in xUnit? |
@shyamnamboodiripad , @AlekseyTs : I remember seeing some kind of a fail fast on test failure in the roslyn unit test infra where we killed the current process on certain failures. Could that be what's going on here? |
@AbhitejJohn In this case a regular Debug.Assert failure causes the crash rather than a test failure. |
Looks like the behavior for Debug.Assert in net core is well known - As @nohwnd points out in microsoft/vstest#2309 one workaround is to use a Example:
|
@AlekseyTs Looks like the roslyn repo already has a
I am not sure whether the app.config is really being hooked up (and if it is why that is not working). Perhaps @jaredpar or @tmat may know more about this... |
Certain data flow analyses use "normalization" to adjust an existing state variable for more variables declared after that state was created. The default behavior is to extend that state to the "top" state, meaning the starting state for that data flow analysis. This is usually the right extension. However, some analysis requires extending the variables the other way, to the bottom state. This PR adds functionality for that customization and also fixes dotnet#41600.
I believe part of the problem is the .NET Core version of xUnit doesn't read |
There are two problems here, the first of which is the most important. First, certain data flow analyses use "normalization" to adjust an existing state variable for more variables declared after that state was created. The default behavior is to extend that state to the "top" state, meaning the starting state for that data flow analysis. This is usually the right extension. However, some analysis requires extending the variables the other way, to the bottom state. This PR adds functionality for that customization. The second problem is that data flow for local functions may include variables that are not captured. This is by filtering the transfer function to only include captured variables. Fixes fixes #41600
It looks like not all scenarios are fixed. Here is how to repro in features/SimplePrograms branch:
Observe:
|
@AlekseyTs this was fixed in test.sdk nuget (16.6.0 I believe). This will get fixed after you update #44442 |
Our tests do not test compiler from SDK, they test the version built locally. |
That is fine, but the Microsoft.NET.Test.SDK (that I called Test.SDK above), is what is bringing the test host that your tests will run in. You need to be at version 16.6.0 or newer to have test host that handles Debug.Assert gracefully. |
The problem is the assert that is being thrown, not how test host reacts to it |
Expected:
x1
is returnedObserved:
x1
andx14
are returned.No repro when
TakeOutParam
andDummy
are changed to be real methods vs. local functions. Still reproduces when onlyTakeOutParam
is converted, butDummy
remains a local function.The text was updated successfully, but these errors were encountered: