Open runfoapp[bot] opened 2 years ago
I took a quick look at the code. The try/finally
block looks suspicious to me. An exception could have been thrown causing the flow to silently go into the finally
block. My guess is that an exception was thrown before the part of the code that reports the expected diagnostics.
Specifically, the FileUtilities.ResolveRelativePath(resolvedPath, baseDirectory);
call.
Note that this is almost only guesses. May or may not be correct.
It seems like my guess isn't correct. I removed the try/finally and the test still fails with the same failure (not crashing with an exception as I was expecting)
My investigations:
there are the following variables and their values:
Variable | Value |
---|---|
directory |
"/" |
baseDirectory |
"/tmp/RoslynTests" |
resolvedDirectoryPath |
"/" |
resolvedDirectoryPath
is supposed to be "/" or not. This comes from FileUtilities.ResolveRelativePath(directory, baseDirectory)
.I hope this provides some entry point for more investigation.
@Youssef1313 Have you been able to repro this by any chance? What does the failure look like? OP doesn't provide much info especially since the CI legs that failed are now out of range of the tracking tool...
@jcouv I couldn't reproduce locally, but I'd expect a repro to be like:
1
in /
(Linux root directory)The questions are:
@jcouv The test no longer fails on CI. Whatever thing was created the /1
file has gone away. But it would be good to try to reproduce on a Linux machine locally and see if it should have failed with the /1
file in the first place.
@333fred Are you still set up on linux? Could you try the repro provided above to see if we still have a bug?
@333fred Are you still set up on linux? Could you try the https://github.com/dotnet/roslyn/issues/58077#issuecomment-1070349349 provided above to see if we still have a bug?
That does indeed reproduce the bug. Steps:
Fact
sudo touch /1 && sudo chown <your_username>:<your_username> /1
dotnet test src/Compilers/CSharp/Test/CommandLine --filter "DisplayName~ArgumentParsing"
Thanks @333fred for the additional linux repro details. I was able to repro and have a fix pending.
Note: the test is skipped in some legs, so the runinfo count below isn't representative of whether it was fixed.