This is an archive of the discontinued LLVM Phabricator instance.

[Path] Fix bug in make_absolute logic
ClosedPublic

Authored by JDevlieghere on Aug 2 2019, 2:04 PM.

Details

Summary

While writing a VFS test case I discovered an issue in the make_absolute implementation for path with a //net style root. These are used in the VFS test cases because they are legal absolute paths on both Windows and unix.

NOTE: in the tests below, we use 'root/' as our root directory, since it is
// a legal *absolute* path on Windows as well as *nix.

The test worked fine for a regular Unix path, which led me to look at the implementation. The problem appears to be that we're trying to use the root name from the relative path, which I believe is incorrect.

Diff Detail

Repository
rL LLVM

Event Timeline

JDevlieghere created this revision.Aug 2 2019, 2:04 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 2 2019, 2:04 PM
labath added a comment.Aug 5 2019, 2:07 AM

There was definitely a problem with the previous implementation, but I don't believe this is quite right either. After all the code you're editing is in the rootName && !rootDir branch, so p should contain a root name, and it makes sense to use that instead of the one in the current dir. I am not super-familiar with this code, but it seems to me that the problem is that you even reach this piece of code for a path like foo.cpp. This happens because we hard-code rootName to true for posix-style paths. This happens to be correct for the "Already absolute?" check, but I'm not sure it's correct for everything that comes after that..

So, I'd try to fix this by splitting the logic for "is this a posix path" from "does this path contain a root name", but it would be nice if someone could confirm that this is the right approach...

I think Pavel's observation is correct and I think this is the correct solution.

labath accepted this revision.Aug 5 2019, 11:37 PM

It looks like the new version shouldn't change the behavior in any other case except the one you ran into (which is obviously wrong), so I'd say this is conservatively correct.

This revision is now accepted and ready to land.Aug 5 2019, 11:37 PM
This revision was automatically updated to reflect the committed changes.