clang-include-cleaner: Failed to apply edits ... No such file or directory

[jleconte2]

intput: ./include-cleaner -p out/Default --edit myfolder/myfile.cc
output: Failed to apply edits to ../../myfolder/myfile.cc: '../../myfolder/myfile.cc': No such file or directory

This was working well in August.
Note that using '--print=changes' instead of '--edit' works well.

[llvmbot]

@llvm/issue-subscribers-clang-include-cleaner

Author: None (jleconte2)

intput: ./include-cleaner -p out/Default --edit myfolder/myfile.cc output: Failed to apply edits to ../../myfolder/myfile.cc: '../../myfolder/myfile.cc': No such file or directory

This was working well in August.
Note that using '--print=changes' instead of '--edit' works well.

[alvestrand]

Note: the build is using the compile commands file, which is using GN, which indeed compiles using "change directory to output directory and compile ../../sourcefile". But include-cleaner should use the same logic for locating the input file and the file to be modified, no matter what the invocation is.

[bc-lee]

My bisect result suggests that the first behavior change is 64d9713, where it changes the symlink handling in clang-include-cleaner.

Minimal reproducer for the issue:

• Create api/main.cpp:

#include <iostream>
#include <thread>  // This line is unnecessary

int main() {
  std::cout << "Hello, world!\n";
  return 0;
}

• Create out/compile_commands.json:

[
  {
    "file": "../api/main.cc",
    "directory": "/path/to/project/out",
    "command": "/usr/bin/g++ -std=c++11 -c ../api/main.cc -o main.o"
  }  
]

• Run clang-include-cleaner -p out --edit api/main.cc where current directory is /path/to/project.

Before this commit, EditedFiles field contains absolute path of the input files. After the commit, it contains the raw path of the input files given in compile_commands.json. In the above example, the input file is ../api/main.cc. However, we are invoking clang-include-cleaner from /path/to/project, so the input file is /path/to/project/../api/main.cc. This causes one of two problems:

• If the parent directory of wrong path exists, clang-include-cleaner will write in the wrong directory.
• If the parent directory of wrong path does not exist, clang-include-cleaner will fail to write the file with "Failed to apply edits to" error.

I think the correct behavior should reflect the "directory" field in compile_commands.json to the path of the input files. Apparently, when I debug Action, getCompilerInstance().getFileManager().getVirtualFileSystem().getCurrentWorkingDirectory() gives correct compiler invocation path, not the path of current working directory of clang-include-cleaner, so I think I can use this path to get the correct path of the input files.

PR for fixing this issue: #111375