-
Notifications
You must be signed in to change notification settings - Fork 831
Fix some possibly buggy usage of UseDiagnosticsLogger
#16753
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
Conversation
|
|
This is only tangentially related, but I replaced the instances where we don't intend to ever unwind: let _holder = UseDiagnosticsLogger diagnosticsLoggerwith SetThreadDiagnosticsLoggerNoUnwind diagnosticsLoggerwhich does not allocate a disposable and makes it easier to later test for correct order of unwinds. |
psfinaki
left a comment
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.
I think this moves us to the safer side. Thanks!
|
/azp run |
|
Azure Pipelines successfully started running 2 pipeline(s). |
Description
There was some odd behavior I noticed while trying to test AsyncLocal diagnostics state.
UseDiagnosticsLoggercreates a diagnostics scope and should restore previous logger on dispose. This should in theory work consistently, pushing and unwinding loggers in the given order. I noticed the disposals often happen out of order, leading to momentarily inconsistent state.By chance I stumbled upon what I believ are some slight bugs in ParseAndCheckInputs.fs:
fsharp/src/Compiler/Driver/ParseAndCheckInputs.fs
Lines 1390 to 1401 in 3ec9b18
This function returns a cancellable, so the disposables will get disposed immediately instead of participating in the cancellable execution.
Similar situation here:
fsharp/src/Compiler/Driver/ParseAndCheckInputs.fs
Lines 1857 to 1881 in 3ec9b18
Disposal happens immediately, leaving us with other global diagnostic logger than expected.
Let's see if fixing this breaks something else.