[PATCH] D46602: [clang-tidy] Store checks profiling info as YAML files

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In https://reviews.llvm.org/D46602#1095960, @alexfh wrote:

> In https://reviews.llvm.org/D46602#1092902, @lebedev.ri wrote:
>
> > In https://reviews.llvm.org/D46602#1092890, @alexfh wrote:
> >
> > > Roman, it looks to me that a simpler storage scheme would be sufficient. For example, YYYYMMDDhhmmss-InputFileName.cpp.csv.
> > >  Main things are:
> > >
> > > 1. include a timestamp, so there's no need to overwrite old results,
> >
> >
> > Of the input source file?
>
>
> No, current timestamp, when each profile gets dumped.


Ah.
Then i don't understand this at all. Why would we want to do that, exactly?
Just so that we can avoid creating directory structure? Why do we want to avoid that?

>>> 2. include just the name of the file without any parent directories,
>> 
>> That won't work, there are duplicate filenames even in LLVM.
> 
> That's why I suggested to include a timestamp. Each result file will get a unique timestamp as a part of its name (unless the resolution of the timestamp is too coarse - compared to clang-tidy run time - to allow collisions).
> 
>> $ find -iname Path.cpp
>>  ./lib/Support/Path.cpp
>>  ./unittests/Support/Path.cpp
>> 
>>   > 3. put all outputs into the same directory. This way we wouldn't have to create a directory structure and think about stripping a certain prefix (btw, utilities like patch just specify the number of path components to remove from the start, not the actual substring). WDYT?
>>    
>>    I'm not particularly looking forward to having being forced to have n thousands of reports in a single directory :)
> 
> What kind of problems do you expect to have with this? Are you going to look at the result files manually or use a script to aggregate them?


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D46602