In D129973#3688329, @SimplyDanny wrote:

In D129973#3684940, @yvvan wrote:

With this change we don't pass "LocInfo" directly and it seems to break the locations when calling "getCXXOperatorNameRange" for this DeclRefExpr later on. Please fix it. You can introduce another "Create" static method for DeclRefExpr that accepts LocInfo and passes it to the DeclarationNameInfo constructor.

Thank you for the hint! This indeed "fixes" the test references so that they can be reverted to their original state. This is done in D130799.

Instead of a new create method or a new constructor (there are already quite a lot of them with complex signatures), I created a DeclarationNameInfo and passed it to one of the existing creators.

With this change we don't pass "LocInfo" directly and it seems to break the locations when calling "getCXXOperatorNameRange" for this DeclRefExpr later on. Please fix it. You can introduce another "Create" static method for DeclRefExpr that accepts LocInfo and passes it to the DeclarationNameInfo constructor.

I'm not a big objC expert here. The idea looks fine to me and won't affect my workflow. So let's take this patch if nobody comments against it here.

@DmitryPolukhin Sorry, I didn't have time recently. Thanks a lot for taking care!

@mgehre I think we need to adjust denormalize(const IO &) method here to convert \n back properly. It seems I missed it in my patch.

@mgehre From your comment it seems that clang-apply-replacements handles the YAML wrong and does not make the proper conversion back from "\n\n" to "\n"

LGTM

Please, upload patches with context (-U9999).

ok, will do it through svn. i forgot that clang repo is called "cfe" so it's there

This script does not seem to work properly on windows.

I have a commit access but I don't understand how am I supposed to commit (haven't done that for a while). There's no clang svn repo anymore. Do you know what's the current state of repositories and where to commit?

Sorry for delay.
Test added, redundant comments removed.

libclang part is quite small here and looks ok. I would just accept it

Some misleading reformatting fixed.

Sorry for unrelated formatting changes - that's clang-format's work :)

@sammccall
I can't avoid adding extra formatting options because my first attempt to introduce an ordinary clang-format option faced resistance because of not fitting the clang-format purpose to format files.

In D53072#1496317, @sammccall wrote:

My feedback would be:

• I definitely think more control over preserving line breaks would be useful. Actually preserving *blank* lines is an important property. If you see D60605, there are a lot of cases where clang-format wants to delete the line you just added. Maybe we can make MaxEmptyLinesToKeep: 9999999 work in more cases.
• I'm not convinced you need/want to preserve *all* line breaks, isn't it just one? (where the user pressed enter)
• It's unclear why "extraformattingoptions" is needed, rather than just the usual formatting options, or some other parameter. It would be nice to avoid a new library entry point (overload) if possible.
• as far as command-line interface goes, this definitely feels more like a flag than a new tool

@ilya-biryukov
I don't really care how it's used from the tool side. I'm also fine to have a new option in clang-format itself. That's why this review is here - to ask for opinions. It's easy to remove that "ide" part from this patch and just add an option for clang-format instead.
Do you have any other remarks/concerns apart from that?

@ilya-biryukov
What do you think about D53072? It can be polished and combined with this change removing some code from here (which I assume is a good thing).
The idea there is that clang-format knows that it's not allowed to remove new lines and it always marks them with MustBreakBefore.
I'm not sure if anybody needs an executable but I think it's not a big deal to have an extra reformat() function.

Seems so.

Thank you! Sorry that I forgot about the required minor version increment.
I will run tests tomorrow and then I can commit it for you.

Could you please also upload diff with the full context? It's -U9999 for git and quite similar for svn.
Otherwise looks ok.

Now we know that somebody else also uses libclang :)
I the mentioned change I only wanted to follow the same logic as in TypePrinter::printTag to cover more anonymity cases.

Having a separate tool is nice because it allows the client to make it plugable. clang-format sometimes changes options quite significantly and it can be nice if you have a choice which version to pick, otherwise it might be unable to read the configuration you have.

New approach - title and summary are updated.

It's probably not needed because I don't see a path which checked for the fatal errors in 8.0. So i will probably abandon this one or update if it does not cover the case I need.

I've tested it with libclang. If something else is needed for proper clangd args forwarding - let me know.

The tests are improved - now they actually act differently with and without the introduced flag. Also few more cases are covered (see the second added test).

Replace the absolute path with {{.*}} to be independent from the machine.

Good point :)

@djasper
Ok, if there's a possible way to go forward I will find time to provide a better test which behaves differently depending on this check. Also my current patch is a bit bigger than this version.

In D53072#1348033, @djasper wrote:

$ cat /tmp/test.cc
int foo(int a,
           int b) {
      f();
  }

$ clang-format -style="{ColumnLimit: 0}" /tmp/test.cc
int foo(int a,
        int b) {
  f();
}

Is this not what you want? If so, in what way?

In D53072#1342363, @djasper wrote:

I don't quite understand. What you are describing should already be the behavior with ColumnLimit=0 and I think your test should pass without the new option. Doesn't it?

In D55595#1329647, @JonasToth wrote:

One thing: Could you please check the utility-scripts in clang-tidy that create new checks, if they need adjustments? Not sure if we have something in there that relies on the old structure.

Add standard prologue to the new header

In D55595#1328100, @lebedev.ri wrote:

1. Please always upload all patches with full context.
2. There are two places where this pattern exists - this file, and tool/ClangTidyMain.cpp. It clearly leads to such issues, Can this be reworked to be just one file that is simply included in both places?

In D55415#1323120, @bkramer wrote:

I'd be interested in hearing how this is used. I added this feature as an experiment a while back but it simply didn't work as I envisioned it to. Some checks do work but the overall latency makes it unusable in an IDE setting. People repeatedly asked me to remove it because it slows down builds while not adding value.

We can also add an extra variable for it if you care about build time

I generated the wrong diff. This is the proper one.

The fact that so many call-sites decide what to do is pretty error-prone.
There was already at least one issue when this flag was not properly set by some of the call-sites.

Hm. What about another way around? - We have user include paths (-I) and report them to the filesystem. This means that we have specific paths under which nothing can be mmaped and everything else can be. In particular cases we can also report -isystem there. This is quite the same logic as current isVolatile parameter but is set only once for each path.

In D54995#1316457, @ilya-biryukov wrote:

In D54995#1316437, @yvvan wrote:

Ok, no global option.
Why not placing your VolatileFSProvider in clang so that libclang could you it too?

Would be happy to, will need to figure out what to do with PCH and PCM files first. However if we do this on clang level, I believe we should remove the isVolatile flag from the VFS interfaces in the first place.
It would be nice to not loose out on the opportunity to avoid fully loading the PCH files, but that obviously requires passing some flags into the VFS implementation or various hacks (matching on filenames/extensions?) to find out which files are PCHs.
I actually don't know which approach to choose: on one hand, I'd really want to get rid of the isVolatile flag, on the other hand I'd really want to avoid loading large binary files into memory and that requires passing the flags.

Ok, no global option.
Why not placing your VolatileFSProvider in clang so that libclang could you it too?

Instead of forcing some default value let's give the client an ability to force disabled mmap if one desires.

@ilya-biryukov
What do you think about the global settable bool in MemoryBuffer in place of the ifdef from https://reviews.llvm.org/D35200 ? In this case the client on Windows can set it and you're safe that any MemoryBuffer call never mmaps.

No success with unmapping. Buffers are hold by PCMCache in Preprocessor (and the same one in ASTReader) and if I clean them then SourceManger crashed sooner or later on some call that gets data from external files.
So far I have no steps to reproduce the lock on user file so I don't currently know if I try something else.

I'm currently trying out another suggestion - which unmaps memory buffer caches after ASTUnit's Parse or Reparse and is limited to Windows only.
And my aim currently is not only clangd but any other client as well.

According to https://msdn.microsoft.com/en-us/2e9c3174-af48-4fa3-9f6a-fb62b23ed994 - "Unmapping a mapped view of a file invalidates the range occupied by the view in the address space of the process and makes the range available for other allocations".
Also as far as i understand from https://msdn.microsoft.com/en-us/library/ms810613.aspx mapped files can only be edited in other apps as mapped files opened with the same name (OpenFileMapping).

To clarify a little bit - i did not write my own simple app but used libclang in qt creator to reproduce the lock and track the issue. This time I hope to go further, collect flags used by clang and make a simple example.

I was able to lock files last time with mmap. The Windows API calls are CreateFileMappingW (it's in the Path.inc, line 794) and MapViewOfFile (further down). As far as I remember the second call actually creates the lock and is freed only by UnmapViewOfFile in destructor