Okay, thanks for your feedback. Discarding this then. I think I might have found the problematic access in KDevelop already in the meantime ...

Okay, I wasn't aware of the overall situation wrt. threading. Still, couldn't it be useful to at least allow for concurrent read accesses which is probably not a large effort (in contrast to concurrent read and write)? I guess that people might not expect blockForLine() to not be re-entrant, and it seems like the proposed robustification might not add too much overhead for performance and code complexity.

Thanks for having a look. Here is a screenshot of the config page with the new option on it (third from the bottom):

Thanks for reviewing. No idea whether there is a good reason for the action not being created during the rowInserted handling; if not, that seems like the cleaner solution indeed.

Upon reopening a file, we should only update the problems of changed files that got updated. Otherwise we should only grab the TU for the main .cpp file and attach it, such that we can do code completion.

Re-add m_diagnosticsCache with a hopefully correct caching implementation. Differing from the original situation, the new function createExternalProblem() adapts the problems it creates to the specific file they are inserted in. The cache thus only caches the original problems as created by ClangDiagnosticEvaluator::createProblem(). createExternalProblem() makes copies of these with a new copy constructor added to ClangProblem.

I am sorry, I think that I misunderstood how the cache works. Please disregard my previous message. I am wondering where the problem that I've been seeing then comes from, seems like it has a different origin.

I re-tested the behavior on files from an actual project and it showed the same behavior when editing files as described in my last post, regardless of how many files are included from the files that are edited. I noticed that the behavior is different when re-opening files: in this case, problemsForFile() is actually called for a larger set of files (although from only looking at this set of files, it seemed a bit random and it was not clear to me how it is determined, I'll have to dig into the source code for this at some point ...).

Thanks for the info. I didn't spot it at first since it is hidden in a dropdown menu.

Address Milian's comments; remove m_diagnosticsCache.

Thanks for the update. Seems good to me.

I guess the previous situation is still more practical, since by temporarily adding a newline there below the oversized line, it is at least possible to edit that line. With the line cut off, it is impossible to edit. Also, in cases where a line is only slightly oversized (as with the emoji example), with the overpainting it might look just fine, whereas with the cutoff it won't look fine.

If you keep the overpainting, you will just overpaint the next line partially with it, that won't help that much, IMHO.

Take a look at bug 404713.

The summary of this diff reads a bit as if it doesn't noticeably improve behaviour

We trade one bug for another. Which one is worse?

Personally, I don't think that I share the concerns about large tooltips. Even in your screenshot it looks fine to me. Since as written before, it can be very easily hidden if desired (e.g. just by clicking in the editor text area). I'd much rather have as much relevant information at once instead of having to click another "expand" button each time to see more. But that's just my personal opinion. Maybe others can comment too.

Address comments. Now, problems are created for each "requested here" child diagnostic that refers to the current document. This may be more than just the last child diagnostic, since there may be multiple ones referring to the current document.

I think that this change will fix bug 403470 as well.

Thanks for pointing me to the right places.

Interesting, I didn't know about the mode which highlights problematic lines. Thanks a lot for pointing it out. I had to look for it, and it turned out that this setting is at: Settings dialog -> Language Support -> Semantic Code Highlighting block -> Highlight problematic lines. I can't remember deactivating this, so it's probably off by default? It seems potentially very useful though, given that the underlines are sometimes easy to overlook, and the red line highlighting also shows up in the scrollbar minimap as you write. When this setting is active, the region where the problem tooltip shows up indeed makes more sense to me. It still doesn't match up though, for example if there are some whitespace lines before the line with the error, then the tooltip will also show when hovering somewhere over these whitespace lines.

There can be scrollbars in problem reports, see the attached screenshot:

Regarding keyboard navigation, it does not work for combined tooltips unfortunately. However, I wasn't aware of the existence of that feature at all before you asked about it ...

Regarding waiting for the background parser on TestFile destruction, I didn't find a way to query whether a parse job is running or to wait for it, if it was started externally, using existing code (but I'm also not familiar with the codebase). As an alternative, one can do Q_ASSERT(ICore::self()->languageController()->backgroundParser()->isIdle()); in the test cleanup function to ensure that the tests don't leave the background parser running. This might also be a good idea to ensure that the tests don't influence each other in that way.

This new patch (hopefully) addresses the test flakiness that I observed before:
https://phabricator.kde.org/D18567

I moved the code into helper functions and added an initial version of the tests. The tests for having the function and the call in the same file, and for having a chain of template functions in the same file include QEXPECT_FAIL(). In principle it would be easy to generate additional problems for these cases, but then a single actual problem would be represented by multiple problems in the same file. Maybe it would be cleaner to make a single problem have multiple ranges.

Make helper functions and add tests, as requested by Milian.

I just noticed this old bug: https://bugs.kde.org/show_bug.cgi?id=368460
Should the template parameters be put into a separate context?

Yes, the behavior of this patch is as described by Milian.

This is how it looks on my system:

Cosmetic improvement to combined problems and decl tooltip

Change to a single setter for match_cs and exact_match_cs to avoid restriction on call order of functions

QString --> const auto (for real)

I don't think that I have commit rights. Feel free to commit.

QString --> const auto

Update according to Milian's comments

Thanks for reviewing. Regarding the question about which models would have an insensitive exact match, and which ones have sensitive exact matches:

Update according to Milian's comment

You are right, this should be changed. I was under the wrong impression that the original diff worked since it still showed the completion when typing something like "foo1" from the beginning. But actually, if "foo" is already there before and one starts typing at "1", then it failed.

Name: Thomas Schöps, Email: tom dot schoeps aet gmail dot com
Thanks for committing this. I'll try using arcanist next time.

I don't think that I have commit rights.

Thanks for the feedback. I don't think I have commit rights, feel free to commit it for me.

As far as I can tell, the changed function is indeed responsible to determine whether to do *automatic* invocation of KDevelop's completion. Manual invocation by the user is still possible by pressing Ctrl+Space. The automatic word completion by KTextEditor, on the other hand, still works for numbers after this change. But it is far less intrusive since it only shows up after typing a few digits and if there are matching other numbers in the same file. So the probability that it offers useful completions is likely much higher, and I'd personally leave that one as it is.

Thanks for having a look. I assume that the "version" attribute needs to be increased and the "kateversion" does not. I updated the diff accordingly. I don't think that I have any commit rights, can you commit?