The QByteArray was already created the same way, now the intermediate object is just cached. But even if that did not change anything it reduces the number of utf8 conversion as only those lines that actually match anything will be converted.

I wonder if that's actually faster. Here we are creating intermediary copies of the QByteArray only to convert to QString.

Question to @apol: from what I can grasp CMakeTargetItem::m_builtUrl is cmake-internal cuisine so there shouldn't be any need to store it in canonical fashion but rather reason(s) to store it exactly as cmake knows it?

In D18551#405494, @rjvbb wrote:

I can't say that it happens systematically but neither that it does NOT happen systematically, and I mean that in general: re-opening a file you just closed.

Isn't this unavoidable BTW, given that we don't end up with preambles of all files?

Commit message ideally. Truncate the report where applicable.

Is the parser triggered again if the entire project has been parsed already?

Oh, sorry, I forgot to press "Submit" on Phab and thought I posted ASan log here.

please still attach the full ASAN report to your commit - i.e. put it into your commit message

In D18551#404528, @rjvbb wrote:

preambles are not created during the initial import except possibly for the files that opened with the session if the parser is triggered twice for those.

Comment removed.

No, sorry, I am a bit confused by your notation and the fact you seem to consider only files that are open when you start a session and then probably confused myself a bit more while answering.

Remove code used for description.

In D18551#404077, @rjvbb wrote:

If line 3 means "files opened after (1)" then yes, that's probably correct.

where (1) = entire project is parsed on import. Is that correct?

The way I understand it, the proposals are slightly different. Maybe we can summarize them as follows:

Is Milian's suggestion different from mine of setting the flag only when projects are not parsed entirely on import (which may be easier to test for where the flag is set, I haven't checked)?

I'm fine with that, but would prefer never having it. Not all files that are opened will be edited, and the delay caused by creating the preamble after the first edit is probably negligible over the lifetime of a session. It would also allow us to just drop affected preambles when a header is edited — otherwise we might have to recreate all preambles that include the header.

never seen this, please investigate and fix it

But for some reason I'm not getting any tooltips in that reporter at all at the moment.

What I meant is that tooltips in the problem reporter appear when you hover the mouse over an entry, and disappear again when you move the mouse back to the text editor (and certainly when you need to scroll the editor window because the tooltip covers the area where you need to be). But for some reason I'm not getting any tooltips in that reporter at all at the moment.

again: why don't we keep this flag when the file is opened in the editor?

please show the full ASAN report, but the second change looks fine to me - if we get an event during destruction of the tool view action, m_dock may be gone already and thus accessing it may be broken already

tooltips don't take keyboard focus, so I don't understand your first note. also the tooltip only shows up (in the editor) while you keep ALT pressed.

In D18551#402186, @brauch wrote:

To clarify, the patch back then was less about the first-time delay, and more about the delay being there *every* time because of wrong usage of the API. Whether the delay occurs once is arguably a bit less important.

So there should indeed be some real-world benchmarking data to do a cost/benefit analysis that includes the human-in-the-loop aspect and huge projects like the ones Aaron uses. We already have an estimated 10% gain for a full reparse of a small project after its initial import.

To clarify, the patch back then was less about the first-time delay, and more about the delay being there *every* time because of wrong usage of the API. Whether the delay occurs once is arguably a bit less important.

In D18551#401594, @rjvbb wrote:

Aaron, don't your arguments apply to parsing an entire project on startup as well? I can easily imagine that opening and parsing entire projects of the size you mention must have a non-negligible cost regardless of all optimisation and caching that is currently implemented

It definitely does. Sometimes I just cancel it, but sometimes I need the entire index to understand some code. (“Find uses” is very useful for that.)

To put it bluntly: you should have asked that 3 months ago ;)
I really can't remember if I had a specific reason or if this is just the result of a search/replace.

In D17908#401595, @mwolff wrote:

you can pick whatever you prefer for the reviews for now.

do you have commit rights? if so, please feel free to push this directly, otherwise someone from us can take care of that for you

you can pick whatever you prefer for the reviews for now.

Aaron, don't your arguments apply to parsing an entire project on startup as well? I can easily imagine that opening and parsing entire projects of the size you mention must have a non-negligible cost regardless of all optimisation and caching that is currently implemented
There is a setting for this feature. A similar switch for the preamble thing will probably be difficult to label comprehensively but maybe a coupling can be made with the full-project-parse switch?

Obsoleted by https://invent.kde.org/kde/kdevelop/merge_requests/5

Preambles are there to speed up repeated reparsing. Most translation units won't be reparsed in a typical session. Since we pay for every preamble we create, I don't think we should create them unless we've some indication that a file needs to be parsed again. It's pretty safe to assume that a file needs to be reparsed again if we parse it for the second time. There is probably no better indicator, which is why this is the default.

In D17760#401252, @mwolff wrote:

do we have custom patches in our libastyle?

Upload the minimum diff.

we use CXTranslationUnit_CreatePreambleOnFirstParse to get code completion results fast. otherwise the first code completion request would create the preamble, which felt much worse

On my test file, time spent in clang_codeCompleteAt goes down from ~700ms

do we have custom patches in our libastyle? I hope not, but it's been too long for me to remember. If not, then I guess we should get rid of our copy of lbiastyle and just disable kdevastyle if that dependency wasn't found - it's pretty optional anyways.

yes, push to 5.3 and we'll merge it to master

lgtm now, sorry for the delay - can you push that yourself? if not, please tell us your email address and name to associate with the commit

it was measured back then:

Replying to a remark by Milian on D17289 where this idea came up:

Hello all, No I do not have dev account, you can associate this patch to
wcancino@gmail.com

ping?

we use CXTranslationUnit_CreatePreambleOnFirstParse to get code completion results fast. otherwise the first code completion request would create the preamble, which felt much worse

please paste compiler errors instead of showing screenshots

sorry for the long delay. personally, I like what I'm seeing in the video, could you cleanup the patch a little please? and does ensureVisible help maybe?

sorry for the long delay, it sounds like a good idea but the diff is super hard to review since it contains lots of unrelated whitespace changes

great initiative, but could you check if this could be done in a more generic way potentially? if not then I'm all for getting this in as-is otherwise

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

In case someone thinks that creating the pch file when you open a file causes a noticeable lag during the opening process: if so this would also be the case when configuring KDevelop not to parse the entire project on import. I use that mode all the time and never noticed any such lag.

Wouldn't that be an opportunity to add the override specifier? The commit message could state "Fix function signature of ... to override".

lgtm now, note that you now need to push to the new gitlab remote at git@invent.kde.org:kde/kdevelop.git

lgtm, thanks. note that you now need to push to the new gitlab remote (git@invent.kde.org:kde/kdevelop.git) cf. https://invent.kde.org/kde/kdevelop for future reviews

since noone else is using this plugin, I'd say let's push this! @wcancino do you have a developer account? if not, then we can commit this for you. Please then give us your email address to associate with the commit then.

@thomassc: A separate context could help, yes. But if you find alternative ways to handle it, like proposed here, then not using a separate context could potentially work out too. But it feels a bit hackish to handle the template args specially everywhere instead of putting them into a proper context.

It'd be interesting to have an estimate of how much faster this makes that initial parse.

finally got it working, man that old code was broken :D I wrote most of that a really long time ago, and it shows!

In D17289#400446, @rjvbb wrote:

I've tried to unlink certain files after they were created but reverted that again when I started getting crashes in the parser. Not that reverting helped against that...

Yes, I believe that's not going to work. Clang doesn't keep the preamble files open, but expects them to stay.

sadly my initial attempt doesn't work either ;-) I'm looking at this some more now and will let you know once I've found an alternative approach

There are mechanisms to ensure cleanup in any event by removing an open file on POSIX compatibles (close will then

I've had a look at the Clang code. They actually go to some lengths to make sure all temporary files are deleted on a clean exit — they register all open temporary files and clean them up in an exit-time destructor. (See TemporaryFiles in lib/Frontend/PrecompiledPreamble.cpp.) However, this won't work in the case of a crash. They have some mechanisms for cleanup in the case of crashes, but I suspect that this works by setting a signal handler and is thus only available in the stand-alone executable. There are mechanisms to ensure cleanup in any event by removing an open file on POSIX compatibles (close will then automatically delete it), or FILE_FLAG_DELETE_ON_CLOSE on Windows. But that doesn't work for Clang, because they work with paths and don't pass file descriptors around.

No problem, I could work with my patch :)

sorry for the long delay, I just tested this and I can reproduce the crash. But just like Aleix, I'm opposed to the suggested way of fixing it. The patch increases coupling without solving the underlying problem. To me, it looks like the list job simply must not store raw pointers, as that's inherently unsafe when we think about changes being done during the queued signal emission... I think to fix this properly, we need to refactor the listjob, and I have an idea on how to do that (operate on indexed strings instead of items, only lookup item when listjob has finished). I'll try this out now and get back to you afterwards.

This version saves the original TMPDIR value, and adds a wrapper around QProcessEnvironment::systemEnvironment() that restores that original value. To keep changes to a minimum I've added that wrapper to the Core class itself.

lgtm, thanks

I think it's fine to commit this as-is

Updated as discussed.

Where or how can I find what to put in the JSON comments?

Do you think we should check for the version of Plasma to make a distinction between DrKonqi versions?
I think not, the Debug feature is not (yet) very popular, but I would like another opinion.