One more thing: could establishing the project file name not simply be done by a method in the ProjectController class rather than by a dedicated class? Because, in how many different functions would you split that logic?

Arguably that still stands, but it's outside my area of expertise to comment on it.

The current patch I still cannot oversee (though also due to the existing code), so I would have to grab the -1 sign for now if on the jury.

updated as requested.

Drops the potentially unsafe qDebug output in the signal handler, makes handlingSignal an std::atomic_bool (since we can use locks here anyway) and adds copious comments.

Still working on this and waiting on more background info from the Qt Interest ML.

You can't use std::atomic_flag, because it's an `int`.

Any idea how we could test the race-condition scenario? I've been trying by re-raising the signal from just before and just inside the if(handlingSignal) loop and until now it has always been behaving as expected (= the if is executed only once).

Sorry for the delay; I thought this would be straightforward and then ran into questions...

This is determined by hardware support. With relevant architectures I meant architectures on which Qt/KDE applications can run, like x86, PPC, ARM. > These all have lock-free `std::atomic<bool>`, as far as I know.

I guess you can also use `std::atomic_flag`, which is guaranteed to be lock-free, and should offer enough functionality for our use case.

...

Not in the middle of an assignment, but between the read in `if (!handlingSignal)` and the write `handlingSignal = 1` it can be interrupted. That's not atomic.

At least std::atomic<bool> is lock-free on all relevant architectures. (I'm aware that the standard doesn't guarantee it, probably because of some embedded architectures.

Updated as suggested

Where in the code would you want a documentation of the intent of this change?
The best place might be a in the handbook or the project import wizard GUI ... but we're in string freeze, no?

• Dropped the semaphore-based alternative as it would only be less resource-intensive when manhandling pthreads
• moved almost everything back out of the CorePrivate class, keeping only the slot required for QSocketNotifier operation.
• dropped the SIGHUP shortcut, to be resubmitted in the future

I would recommend to just not think about the Windows requirement, if you cannot test it anyway.

If there is no solution which does not require two different code paths for handling this problem, I'm against merging this, non-conformant old behaviour or not, sorry.

• Why does this patch look so much more verbose than the solution proposed on http://doc.qt.io/qt-5/unix-signals.html?

In D16218#343340, @arrowd wrote:

Adds the missing #endif

Re: the testing I did on FreeBSD: that's with a dedicated demonstrator; I cannot currently build KDevelop5 there.

I'd be pushing less if this hadn't already been committed and then reverted because of an issue that got through the initial review process.

In absence of instructions to the contrary I'll interpret Milian's "feel free to respin" as "feel free to recommit", and push a commit during the day. This has been waiting to be re-applied long enough.

Another fix for the generic Makefile project manager; I had missed the fact that URLInfo::isDir is undefined when URLInfo::isValid is false. This lead to personalised project files of the type `/path/to/projectFoo/projectFoo.kdev4/customname.kdev4```.

Updated as discussed. This variant is less different from stock code than my previous proposal. It complements the current checks with a comparison using canonicalised paths. As a result it should catch all cases that are not caught by either one of the comparisons when performed in isolation.

I think there might be a simpler solution to that situation

Updated as discussed: any previous project settings file in .kdev4 will be removed if and before overriding/writing it (instead of simply trashing the entire .kdev4 directory).

I'm doing it now and will test it as part of this patch; afterward there are 3 options

Attributes are not keywords — they're a (C++-specific) generic syntax that was introduced with C++11.
Again, the idea is not starting from scratch, but introducing small changes that reduce the number of errors programmers

In any situation where we'd already be overwriting the settings file but where there are other projects defined in the same sourcetree. The summary of this DR argues how and why that could be the case.

This fixes a mix-up that slipped through and above all, puts deleting the .kdev4 under user control.
Apparently there are situations where this directory should be deleted because its presence (empty) can confuse the project manager when overwriting an existing project (?!, T6262). /Methinks that's something that must be fixed in the confused place(s), not worked around by removing .kdev4. The whole point of this patch is to allow the creation of multiple projects in a single source tree, after all.

Exactly how can the project manager be confused when you don't remove the .kdev4 directory, knowing that it will be recreated almost immediately after deleting it? (In any case I don't see how it could *not* be recreated given that it will hold the new settings file).

You can use comments <https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/>, or `__attribute__((fallthrough))` in C.

Using Q_UNREACHABLE

Latest version still doesn't restore the crash for me, so LG.

__builtin_unreachable() does have strange effects:

I think this could be Q_UNREACHABLE().

Updated as suggested: handle all known language types in languageStandard()

reuse the C(++) parser options for ObjC(++).

• Do we want a -std= flag, does Clang even accept that?

Removed left-over x-objchdr reference (sorry about that).

Removed the x-objchdr mimetype (to avoid additional confusion what a .h file could be) and added my current x-objc+src definition to kdevclang.xml .

So let's first please do some effort to have a MIME type id agreed on by others (ideally this would be something done in the Objective-C++ community where you might have your contacts to poke)

I am slighty uneasy with the explosion of code we add now

"this commit is the patch which is reviewed there".

Looks like you nailed it this time.

Then I don't understand the question.

I don't see how that answers my question?

If I may: can someone please tell me why it should be impossible that only small items are found, IOW why there would also have to be something to shrink?

In D15625#331133, @amhndu wrote:

The reasoning was that Items that have maximumWidth size needn't be shrinked, as that's the maximum size that's allowable.

See also https://bugs.kde.org/show_bug.cgi?id=399025

Can you guarantee that rect.width (height) will never be equal to the RHS in the equation from my previous reply?

Another thought: are you sure the comparison should be itemWidth <= maximumWidth and not a simple < instead? That ought to address the situation I run into, though I still don't believe it'd be a guarantee that there will never be other situations where all items are considered to be small items.

Interestingly, I'm getting the same issue on Linux (with the same QtCurve style though a slightly different font selection).
Only here it's maximumHeight that is concerned, not the width.

How exactly is maximumWidth calculated to be 0?

It works and can go in with just one minor change request.

As discussed earlier, switch statements do have a weird syntax and I'm completely with you if you don't like it. They are basically a glorified `goto` cascade. The case labels actually behave like `goto` labels in a lot of ways, which is the basis of oddities like Duff's device

When it comes to no `break;` after a `return;`, that also matches the idea to not have an `else` after an `return` in the branch before.

Sure, I am mainly interested here that we use MIME type ids which also accepted elsewhere, and not invent our own here and ignore the rest of the world :)
Once e.g. shared-mime-info has some version accepted, we can then provide fall-back variants in the kdevelop s-m-i files installed.

Can you explain in more detail how an unreachable `break` after a `return` statement makes the code more readable?

As mentioned on another ticket, I don't like the idea of not putting breaks, no matter how clever the compiler and hard-coded choice of compiler options; I don't think you gain anything from it, and it doesn't improve code readability either for me (esp. when switch cases aren't indented w.r.t the switch context, as in the last hunk in plugins/qmljs/codecompletion/context.cpp.
Making it obligatory to add a token confirming that fallthrough is intended is a good idea, though using a largish term in all-caps like Q_FALLTHROUGH also doesn't improve readibilty. And what about the most common type of fallthrough, are we really going to have to write something like the following?

Doesn't KDevelop already add (install) a few mimetypes of its own? I think I mentioned before that I do have a .xml file for SMI, adding the x-objc++src definition and I presume that's why I am not seeing mimetype warnings about ObC (I'm seeing others though.)

I have no (big) problems with a fallthrough attribute, but if it's going to be obligatory I'd want the complementary attribute (the break) to be obligatory too...

In D15530#329968, @aaronpuchert wrote:

You should probably also add a few lines to the custom-definesandincludes plugin.

Eventually we have to compile our code anyway, so aren't we all dependent on the compiler?

Refactored for the 5.3 branch + completed.

"If you have inherited this class to access the formatter, you will need to add a method similar to getPeekStart() in the ASStreamIterator class in astyle_main.h." from http://astyle.sourceforge.net/news.html is the only info I have, which leaves lots of room.
Have you seen any docs for that method?

Updated as suggested. No switch yet but a layout that looks more like one.

Looks good at first glance. The failsafe should work evidently but I'll have to test to be certain if the other fix prevents the situation I ran into. Maybe this afternoon, otherwise tomorrow.

You should probably also add a few lines to the custom-definesandincludes plugin.

Would this be OK as a fix?

Is there some API dox what one should implement for getPeekStart(), especially which values are valid?