[PATCH] D49890: Clang-Tidy Export Problem

[Johnny Willemsen via Phabricator via cfe-commits]

jwillemsen added a comment.

I am trying to use run-clang-tidy on ACE/TAO (see 
https://github.com/DOCGroup/ACE_TAO) but it doesn't work, also the error 
reported here. When only running modernize-use-override I get a yaml file of 
110167 lines but that can't also be applied using clang-apply-replacements, 
same errors.

The last proposed change to run-clang-tidy.py doesn't work for me.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D49890/new/

https://reviews.llvm.org/D49890

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ng Zhi An via Phabricator via cfe-commits]

ngzhian added a comment.

I found this patch while searching for a similar problem I faced while tryin to 
use clang-tidy to fix some warnings in V8 (Chrome's JavaScript engine).
The setup for our compilation is as such:

- basedir
  - src/
  - out/ -arch1/
  - .o files, generated files
  - compile_commands.json
- arch2/

We use ninja to build, so usually with a command like `ninja -C out/arch1`, 
this means (roughly) cd into out/arch1 and build.

Given this, I have an alternative suggestion for a fix. In run-clang-tidy.py 
apply_fixes, we call the clang-apply-replacement with cwd set to build_path, 
like so:

  diff --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py 
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  index 1eb13529575..cde9e3671af 100755
  --- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  +++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  @@ -150,7 +150,7 @@ def apply_fixes(args, tmpdir):
 if args.style:
   invocation.append('-style=' + args.style)
 invocation.append(tmpdir)
  -  subprocess.call(invocation)
  +  subprocess.call(invocation, cwd=args.build_path)

def run_tidy(args, tmpdir, build_path, queue, lock, failed_files):

I don't know the internals of clang-tidy enough to do this, but it works for 
me. And it seems reasonable, since the Replacement FilePath in the yaml file 
consumed by clang-apply-replacement was generated as a path relative to the 
build_path anyway. For now this is a sufficient hack for my use case (tried 
with with just 1 data point as a test), and it will be good to get feedback if 
this fix is correct. Thanks!


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D49890/new/

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Kevin Funk via Phabricator via cfe-commits]

kfunk added a comment.

Is someone willing to pick up this patch again? It's still an issue.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D49890/new/

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad added a comment.

Hi @alexfh,
I have attached the compilation database for `MPlayer-1.3.0`.F7659818: 
compile_commands.json 
As can be seen, the paths are relative. To answer your comments I need more 
time. I do not remember the exact details. I will prepare a test as soon as 
possible. I did not use the test infrastructure, before. Therefore, I should 
learn about it.
Regards.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D49890/new/

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh requested changes to this revision.
alexfh added a comment.
This revision now requires changes to proceed.

In D49890#1200061 , @TheAhmad wrote:

> In D49890#1182556 , @alexfh wrote:
>
> > Could you describe the specific problem you're solving and provide an 
> > example? As mentioned by others, a test would be very welcome as well.
>
>
> Sorry for so much delay,  @alexfh. I didn't see your comment. I will describe 
> in detail:
>  I wanted to do a source to source transformation on `MPlayer-1.3.0` source 
> code. The transformation may require modification of many files and possibly 
> repeated modifications in the headers files included in multiple `.c` files. 
> Therefore, the changes should be serialized for each translation unit and 
> stored in a `YAML` file. At the end, `clang-apply-replacements` will be 
> called and transform the entire source code.
>  The problem is that `clang-tidy` expects a limited format for the 
> compilation database. This is the format typically used when the build system 
> generating the compilation database is `CMAKE`.  But `MPlayer` uses 
> `Makefile`. Therefore, I had to use an external database generator, `Bear`.  
> In this case, the contents of the `YAML` files are OK. But it is not what is 
> expected by `clang-tidy`.  `clang-tidy` requires every file path to be 
> absolute, even the header files.
>  The problem (i.e., using relative paths) only arises when the fixes are 
> `exported`. Not when they are applied `in-place`. I reused some of the code 
> for the in-place case and did some modifications to it. The code is OK, at 
> least for my case with `MPlayer`. A small change is still needed to support 
> `merge conflicts` which can be brought from the `in-place fix` stuff. It 
> seems that at the end the commanlities of the two cases should be put in a 
> function. Then this function can be called from both places (i.e., the 
> `in-place fix` and the `export fix`).
>  I am new to `Clang` and do not know what is needed for tests. I am looking 
> forward to your reply.
>  Regards.


Sorry for missing your reply (vacation, travels - and a lot of mail got buried 
under other mail). Feel free to ping regularly, if you don't get a response.

The solution you propose seems reasonable, but 1. we need a test, 2. I would 
like to better understand where relative paths are coming from (`directory`? 
include search paths in the compilation command?). Could you upload an example 
of a problematic compilation database?




Comment at: ClangTidy.cpp:614
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)

TheAhmad wrote:
> JonasToth wrote:
> > TheAhmad wrote:
> > > Eugene.Zelenko wrote:
> > > > Type is not obvious, so please don't use auto.
> > > Hi, Eugene. Why line 352 uses auto?
> > He means line 615 (`InitialWorkingDir`). The type of the variable can not 
> > be deduced from reading the code.
> > 
> > The rule is, to write the type once. E.g. `llvm::make_unique(args)` 
> > makes it clear, that the type is `MyType`, so you can use `auto` for the 
> > variable.
> > This is not the case for `InitialWorkingDir`.
> Right. I agree. So `line 352` should not use `auto` either.
Agree. Line 352 should use explicit type.



Comment at: ClangTidy.cpp:612
+
+  auto Files = make_unique(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();

Should we get the file manager from the SourceManager as in handleErrors?



Comment at: ClangTidy.cpp:632
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::make_pair(ErrorAbsoluteFilePath, 
AbsoluteError));
+}

I'd use `try_emplace` instead.


Repository:
  rCTE Clang Tools Extra

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D49890/new/

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad added a comment.

In https://reviews.llvm.org/D49890#1182556, @alexfh wrote:

> Could you describe the specific problem you're solving and provide an 
> example? As mentioned by others, a test would be very welcome as well.


Sorry for so much delay,  @alexfh. I didn't see your comment. I will describe 
in detail:
I wanted to do a source to source transformation on `MPlayer-1.3.0` source 
code. The transformation may require modification of many files and possibly 
repeated modifications in the headers files included in multiple `.c` files. 
Therefore, the changes should be serialized for each translation unit and 
stored in a `YAML` file. At the end, `clang-apply-replacements` will be called 
and transform the entire source code.
The problem is that `clang-tidy` expects a limited format for the compilation 
database. This is the format typically used when the build system generating 
the compilation database is `CMAKE`.  But `MPlayer` uses `Makefile`. Therefore, 
I had to use an external database generator, `Bear`.  In this case, the 
contents of the `YAML` files are OK. But it is not what is expected by 
`clang-tidy`.  `clang-tidy` requires every file path to be absolute, even the 
header files.
The problem (i.e., using relative paths) only arises when the fixes are 
`exported`. Not when they are applied `in-place`. I reused some of the code for 
the in-place case and did some modifications to it. The code is OK, at least 
for my case with `MPlayer`. A small change is still needed to support `merge 
conflicts` which can be brought from the `in-place fix` stuff. It seems that at 
the end the commanlities of the two cases should be put in a function. Then 
this function can be called from both places (i.e., the `in-place fix` and the 
`export fix`).
I am new to `Clang` and do not know what is needed for tests. I am looking 
forward to your reply.
Regards.




Comment at: ClangTidy.cpp:614
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)

JonasToth wrote:
> TheAhmad wrote:
> > Eugene.Zelenko wrote:
> > > Type is not obvious, so please don't use auto.
> > Hi, Eugene. Why line 352 uses auto?
> He means line 615 (`InitialWorkingDir`). The type of the variable can not be 
> deduced from reading the code.
> 
> The rule is, to write the type once. E.g. `llvm::make_unique(args)` 
> makes it clear, that the type is `MyType`, so you can use `auto` for the 
> variable.
> This is not the case for `InitialWorkingDir`.
Right. I agree. So `line 352` should not use `auto` either.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Alexander Kornienko via Phabricator via cfe-commits]

alexfh added a comment.

Could you describe the specific problem you're solving and provide an example? 
As mentioned by others, a test would be very welcome as well.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad updated this revision to Diff 157846.
TheAhmad marked 4 inline comments as done.
TheAhmad added a comment.

auto used at line 612.
auto removed at line 614.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890

Files:
  ClangTidy.cpp


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,56 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  auto Files = make_unique(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  llvm::ErrorOr InitialWorkingDir =
+  FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath =
+static_cast(Error.Message.FilePath);
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::make_pair(ErrorAbsoluteFilePath, 
AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::make_pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,56 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  auto Files = make_unique(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  llvm::ErrorOr InitialWorkingDir =
+  FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath =
+static_cast(Error.Message.FilePath);
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::make_pair(ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::make_pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D49890: Clang-Tidy Export Problem

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

Actually, maybe this patch is relevant for clang-tooling itself (where the 
compilation-database stuff actually is). @alexfh what is your opinion on that?

`llvm/tools/clang/unittests/Tooling/CompilationDatabaseTest.cpp` This is the 
path for the unittests there.
`llvm/tools/clang/tools/extra/unittests/clang-tidy` This is the path for the 
clang-tidy unittests, where the tests for this patch should land.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: ClangTidy.cpp:614
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)

TheAhmad wrote:
> Eugene.Zelenko wrote:
> > Type is not obvious, so please don't use auto.
> Hi, Eugene. Why line 352 uses auto?
He means line 615 (`InitialWorkingDir`). The type of the variable can not be 
deduced from reading the code.

The rule is, to write the type once. E.g. `llvm::make_unique(args)` 
makes it clear, that the type is `MyType`, so you can use `auto` for the 
variable.
This is not the case for `InitialWorkingDir`.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad added a comment.

> Also, tests.

What should I provide for tests?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad added a comment.

The most comprehensive fix is to support all possible valid compilation 
databases. The current fix is the fastest one.

> Can you just make clang-tidy respect the directory value?

This is exactly what I did. I prepended the directory value to the file value 
and stored the result in the exported file.
There was also problem with merges to the same location. What I did is similar 
to the code for `inplace fix` (starting at `line 133` of `ClangTidy.cpp`), 
except that I have not added the code for merge conflicts. The ultimate fix 
requires adding a new function and moving the shared code there. Then `inplace 
fix` and `export` will use that function.




Comment at: ClangTidy.cpp:614
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)

Eugene.Zelenko wrote:
> Type is not obvious, so please don't use auto.
Hi, Eugene. Why line 352 uses auto?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D49890#1178211, @JonasToth wrote:

> In https://reviews.llvm.org/D49890#1178103, @lebedev.ri wrote:
>
> > I'm not sure what this differential *actually* does.
>
>
> This is a follow up from this discussion on the mailing list: 
> http://clang-developers.42468.n3.nabble.com/Fwd-Running-Clang-Tidy-on-a-Large-Project-td4061261.html


No, i saw that. But i'm still unable to parse the code.
It's a little bit hard to argue about the diff without the tests.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: ClangTidy.cpp:612
+
+  std::unique_ptr Files =
+  make_unique(FileSystemOptions());

in this case you can use `auto` again, because the type of the `unique_ptr` is 
clear from the `make_unique` call.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

In https://reviews.llvm.org/D49890#1178103, @lebedev.ri wrote:

> I'm not sure what this differential *actually* does.


This is a follow up from this discussion on the mailing list: 
http://clang-developers.42468.n3.nabble.com/Fwd-Running-Clang-Tidy-on-a-Large-Project-td4061261.html


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

Also, please upload the patches with full context (`-U9`), and the patch is 
misformed, the `ClangTidy.cpp` isn't in the root directory.
Also, tests.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

I'm not sure what this differential *actually* does.

That being said
https://clang.llvm.org/docs/JSONCompilationDatabase.html#format

> directory: The working directory of the compilation. All paths specified in 
> the command or file fields must be either absolute or relative to this 
> directory.
>  file: The main translation unit source processed by this compilation step. 
> This is used by tools as the key into the compilation database. There can be 
> multiple command objects for the same file, for example if the same source 
> file is compiled with different configurations.

Can you just make clang-tidy respect the `directory` value?
If `directory` is invalid, then it is not a valid Compilation Database to begin 
with..


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad updated this revision to Diff 157676.
TheAhmad marked 4 inline comments as done.
TheAhmad added a comment.

Used make_pair instead of constructor call.
Used unique_ptr.
Used named cast.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890

Files:
  ClangTidy.cpp


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,56 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  std::unique_ptr Files =
+  make_unique(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath =
+static_cast(Error.Message.FilePath);
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::make_pair(ErrorAbsoluteFilePath, 
AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::make_pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,56 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  std::unique_ptr Files =
+  make_unique(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath =
+static_cast(Error.Message.FilePath);
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::make_pair(ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::make_pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 
___
cfe-commits mailing list

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad updated this revision to Diff 157667.
TheAhmad marked an inline comment as done.
TheAhmad added a comment.

Added auto at line 612.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890

Files:
  ClangTidy.cpp


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,55 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  auto Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(
+  ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,55 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  auto Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(
+  ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: ClangTidy.cpp:612
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();

Eugene.Zelenko wrote:
> You could use auto here, because type is in new statement.
Where will the `delete` happen for the FileManager? I think a `unique_ptr` 
would be a good idea, not?

you can use `llvm::make_unique<>()` to reduce the verbosity of C++11.



Comment at: ClangTidy.cpp:624
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);

Please use a named cast for your intended purpose.



Comment at: ClangTidy.cpp:630
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(
+  ErrorAbsoluteFilePath, AbsoluteError));

You could maybe use `std::make_pair` here.



Comment at: ClangTidy.cpp:657
+
+AbsoluteError.Fix.insert(std::pair(File, Repls));
+

`make_pair` too.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: ClangTidy.cpp:612
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();

You could use auto here, because type is in new statement.



Comment at: ClangTidy.cpp:614
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)

Type is not obvious, so please don't use auto.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad accepted this revision.
TheAhmad marked 3 inline comments as done.
TheAhmad added a comment.
This revision is now accepted and ready to land.

Thanks Eugene!


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad updated this revision to Diff 157623.
TheAhmad added a comment.

Ran Clang Format.
Redundant Braces Removed.
Used auto.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890

Files:
  ClangTidy.cpp


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,55 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(
+  ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,55 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
   for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+if (!Error.BuildDirectory.empty())
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end()) {
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(
+  ErrorAbsoluteFilePath, AbsoluteError));
+}
+
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+   Repl.getLength(), Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError AbsoluteError = SingleErrors.find(File)->second;
+if (SingleErrors.find(File) == SingleErrors.end())
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+
+AbsoluteError.Fix.insert(std::pair(File, Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: ClangTidy.cpp:620
+  llvm::StringMap SingleErrors;
+  for (const ClangTidyError  : Errors) {
+if (!Error.BuildDirectory.empty()) {

You could use auto, since it's iterator over container.



Comment at: ClangTidy.cpp:621
+  for (const ClangTidyError  : Errors) {
+if (!Error.BuildDirectory.empty()) {
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);

Curly braces are not necessary.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added inline comments.



Comment at: ClangTidy.cpp:627
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end())
+{

Please run Clang-format.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D49890: Clang-Tidy Export Problem

[Ahmad Nouralizadeh via Phabricator via cfe-commits]

TheAhmad created this revision.
TheAhmad added a reviewer: alexfh.
TheAhmad added a project: clang-tools-extra.

Hi.
Clang tidy has problem with compile command databases that do not use 
necassarily absolute file paths. This is common in many projects that use 
makefiles as the build system, whose databases are usually generated using 
Bear. Therefore, I reused some of the code of the in-place fix and revised it 
to generate a YAML export file. The diff is OK, except that the merge conflicts 
are not added, right now.
Thanks!


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D49890

Files:
  ClangTidy.cpp


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,58 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
-  for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
+  for (const ClangTidyError  : Errors) {
+if (!Error.BuildDirectory.empty()) {
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+}
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end())
+{
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  
SingleErrors.insert(std::pair(ErrorAbsoluteFilePath, 
AbsoluteError));
+}
+   
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+ Repl.getLength(),
+ Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();
+Replacements Repls = FileAndReplacements.second;
+
+ClangTidyError  AbsoluteError = SingleErrors.find(File)->second;   
+if (SingleErrors.find(File) == SingleErrors.end())
+{
+  llvm::report_fatal_error("Cannot find the containing ClangTidyError.");
+}
+AbsoluteError.Fix.insert(std::pair(File,Repls));
+
+tooling::Diagnostic Diag = AbsoluteError;
 TUD.Diagnostics.insert(TUD.Diagnostics.end(), Diag);
   }
 


Index: ClangTidy.cpp
===
--- ClangTidy.cpp
+++ ClangTidy.cpp
@@ -608,8 +608,58 @@
 raw_ostream ) {
   TranslationUnitDiagnostics TUD;
   TUD.MainSourceFile = MainFilePath;
-  for (const auto  : Errors) {
-tooling::Diagnostic Diag = Error;
+
+  FileManager *Files = new FileManager(FileSystemOptions());
+  vfs::FileSystem  = *Files->getVirtualFileSystem();
+  auto InitialWorkingDir = FileSystem.getCurrentWorkingDirectory();
+  if (!InitialWorkingDir)
+llvm::report_fatal_error("Cannot get current working path.");
+
+  llvm::StringMap FileReplacements;
+  llvm::StringMap SingleErrors;
+  for (const ClangTidyError  : Errors) {
+if (!Error.BuildDirectory.empty()) {
+  FileSystem.setCurrentWorkingDirectory(Error.BuildDirectory);
+}
+
+SmallString<128> ErrorAbsoluteFilePath = (StringRef)Error.Message.FilePath;
+Files->makeAbsolutePath(ErrorAbsoluteFilePath);
+if (SingleErrors.find(ErrorAbsoluteFilePath) == SingleErrors.end())
+{
+  ClangTidyError AbsoluteError = Error;
+  AbsoluteError.Message.FilePath = ErrorAbsoluteFilePath.str();
+  AbsoluteError.Fix.clear();
+  SingleErrors.insert(std::pair(ErrorAbsoluteFilePath, AbsoluteError));
+}
+	
+for (const auto  : Error.Fix) {
+  for (const auto  : FileAndReplacements.second) {
+SmallString<128> FixAbsoluteFilePath = Repl.getFilePath();
+Files->makeAbsolutePath(FixAbsoluteFilePath);
+
+tooling::Replacement R(FixAbsoluteFilePath, Repl.getOffset(),
+		  Repl.getLength(),
+		  Repl.getReplacementText());
+
+FileReplacements[R.getFilePath()].add(R);
+  }
+}
+
+FileSystem.setCurrentWorkingDirectory(InitialWorkingDir.get());
+  }
+
+  for (const auto  : FileReplacements) {
+StringRef File = FileAndReplacements.first();