Page MenuHomePhabricator

[VirtualFileSystem] InMemoryFileSystem::status: Return a Status with the requested name (take 2)
AbandonedPublic

Authored by simark on Jul 25 2018, 8:49 AM.

Details

Summary

This is a new version of D48903, which has been reverted. @ioeric fixed
the issues caused by this patch downstream, so he told me it was good to
go again. I also fixed the test failures on Windows. The issue is that
the paths returned by the InMemoryFileSystem directory iterators in the
tests mix posix and windows directory separators. This is because we do
queries with posix-style separators ("/a/b") but filenames are appended
using native-style separators (backslash on Windows). So we end up with
"/a/b\c".

I fixed the test by re-using the ReplaceBackslashes function defined in
another test. I'm not sure this is the best fix, but the only
alternative I see would be to completely rewrite tests to use
posix-style paths on non-Windows and Windows-style paths on Windows.
That would lead to quite a bit of duplication...

Here's the original commit message:

InMemoryFileSystem::status behaves differently than
RealFileSystem::status. The Name contained in the Status returned by
RealFileSystem::status will be the path as requested by the caller,
whereas InMemoryFileSystem::status returns the normalized path.

For example, when requested the status for "../src/first.h",
RealFileSystem returns a Status with "../src/first.h" as the Name.
InMemoryFileSystem returns "/absolute/path/to/src/first.h".

The reason for this change is that I want to make a unit test in the
clangd testsuite (where we use an InMemoryFileSystem) to reproduce a
bug I get with the clangd program (where a RealFileSystem is used).
This difference in behavior "hides" the bug in the unit test version.

Diff Detail

Event Timeline

simark created this revision.Jul 25 2018, 8:49 AM
simark abandoned this revision.Jul 25 2018, 9:08 AM