Ok, I take it that space optimizations could also be done later if necessary. I will merge it then after correcting the comment.

Do you have commit access or should I commit this for you?

Otherwise it's fine.

In D14694#305531, @kossebau wrote:

it is unique in its use, one cannot mix it up with the search actions when scanning the menus and toolbars just by icons

Maybe this has been discussed before, but I think something like a magnifying glass (search) would be more appropriate. The check mark suggests that the code is "verified", in the sense that it's definitely fine, but most (all?) static analysis tools don't guarantee that. If the tool finds something, then something is probably wrong, but if it doesn't, there could still be a mistake.

Maybe you can also activate the warning (as error) in CMakeLists.txt?

In D14304#304677, @kossebau wrote:

In the case of the include path removing a path entry does not feel like one is deleting data, as the string is an existing dir (at least usually). So it is more like adding & removing existing items (the paths) to and from a list.

What about the custom include paths? Still have a list-remove icon there. They are easy to restore though.

Nice. Having this information better structured and accessible is definitely a good thing!

In D13613#297384, @arrowd wrote:

This should've been closed by https://phabricator.kde.org/R32:484eee3f6386cc8c9c0e3282abeddb9658770211

Left that improvement though for a latter separate patch, until the flag addition in general are accepted.

Maybe @mwolff wants to have a look again, but I think it's fine.

In D13613#291301, @arrowd wrote:

Files that are absent on FreeBSD are listed here. So, let's just use first one in lexicographics order: adxintrin.h.

On my system,

In D11136#248743, @apol wrote:

In D11136#248120, @mschwarz wrote:

I second @aaronpuchert - it would be better to remove support for other compilers than the one that is actually used for parsing.

If that's the case, I suggest someone to suggest a plan towards deprecating custom-definesandincludes.

The custom- part is obviously still Ok. But I think simulating another compiler is beyond the scope of libclang and will never completely work.

On the surface the compiler is right, this comes very close to undefined behavior. But there is so much crazy stuff happening in the DUChain that it might be fine in the end.

In D13613#282425, @arrowd wrote:

clang -ferror-limit=100 -fspell-checking  -Wunused-parameter -Wunreachable-code -Wall -std=c++11 -nostdinc -nostdinc++ -xc++ -isystem/usr/include/c++/v1 -isystem/usr/lib/clang/6.0.0/include -isystem /usr/local/llvm60/lib/clang/6.0.0/include -imacros /tmp/test_problems.zWlSBE /tmp/testfile_HVezBz.cpp

That's the part I don't understand. Why is the C++ standard library include directory /usr/include/c++/v1/ builtin, but the C standard library directory /usr/include isn't? Here's what I get:

Not sure why I didn't notice in D7693 that this doesn't work properly, so I fixed it here.

In D13613#282070, @arrowd wrote:

In D13613#281953, @aaronpuchert wrote:

I'm not sure if <vector> includes system headers, but I replaced it with <cstdlib>, which obviously includes <stdlib.h> from /usr/include. That still works here.

In the test source?

I guess this comes from the second test row ("ignore-moc-at-end")? I'm not sure if <vector> includes system headers, but I replaced it with <cstdlib>, which obviously includes <stdlib.h> from /usr/include. That still works here.

In D13613#281365, @arrowd wrote:

I was asking what's the right way. Do you think I should change the test?

But test_problems test doesn't use this analyzing the code. Maybe the code for the test itself should be changed?

The include directories should be provided by the custom-definesandincludes plugin, specifically the compiler provider. See GccLikeCompiler::includes in plugins/custom-definesandincludes/compilerprovider/gcclikecompiler.cpp. Why does that not work?

The failures probably came from my change D8634, thanks for fixing it. The commit you mentioned seems to precede that.

As discussed with VDG, color the scrollbar with the same colors as the terminal color scheme itself. It looks way cleaner and modern

The Clang developers work really hard on compatibility with both GCC and MSVC, but I don't think they want to use the same defines and includes for that. For example, both Clang and GCC have their own private header files (on my machine, /usr/lib64/gcc/x86_64-suse-linux/7/include and /usr/lib64/clang/5.0.1/include/). These are quite similar, but not interchangeable. I don't think one can use one set of headers with the other compiler.

In D11136#221589, @mwolff wrote:

Hmm I was actually thinking about _removing_ most of the non-clang compiler stuff (builtin macros, includes etc) - but I'd like to discuss this first

@rjvbb You certainly have a point when you say that there are more deficits to address, but nothing will ever get done unless someone does it. Nobody here is claiming that this solves all problems, but I don't see how it would hinder further improvements down the road, including those that you have sketched.

In D9824#192793, @rjvbb wrote:

If real-world impact is in the order of a highly significant but millisecond-order reduction of reaction time to file change there may be little reason to commit this improvement now (and then risk forgetting about the rest again). My hunch is that it could be more effective then to keep this change pending and use it as a motivation to work on a more complete overhaul of the class.

I'm fine with the change otherwise, but I think @kfunk and/or @brauch should have a chance to revise or reaffirm their position.

@mwolff Are the additional changes Ok? There are no new warnings anymore.

Fix remaining occurences of -Wcovered-switch-default.

In D9316#179221, @kfunk wrote:

It's adding code which we need to maintain (what if the KSelectionProxyModel::FilterBehavior enum is extended?)

Since MultiLevelListView::FilterBehavior is translated into KSelectionProxyModel::FilterBehavior, there should be no problem if the latter is extended. Of course one could think about also extending the former then, but I don't see something terrible happen if we don't.

In D9236#177787, @kossebau wrote:

I still have to complete my C++11 classes sadly. In my naive mind I would have hoped something like this would be possible, in general:

alloc heap memory for list items
for each item
    default constructor item on heap
    setup item on heap

I would not see any principal need to prepare the item on the stack. Is there? Why would C++11 still prefer a move operator, instead of going directly for the final memory destination?

By the way, it's usually a good idea to have vector elements nothrow-move constructible. This can be checked with

It might not actually be faster though, because you go through the memory twice. If the vector doesn't fit into the cache, that could introduce quite some slowdown.

Fix -Wcovered-switch-default where it is safe to do so.

There are no issues with -Wswitch, but some with -Wcovered-switch-default.

Good idea, -Wswitch is a nice tool. But it doesn't seem activated in the builds, at least with Clang.

Made sure switches over enums cover all values, and used more auto.

In D8634#163888, @mwolff wrote:

I figured - couldn't we simply replace ParserArguments with e.g. a QHash<Utils::LanguageType, QString>? Or, better yet, we make it a QString[Utils::LanguageType::Other]?

There is still that flag parseAmbiguousAsCPP, but I like the idea of using an array. Maybe we can get rid of the flag, but I wouldn't want to do too much in one change.

Incorporated review by Milian:

It is indeed a mystery. Note that the member function isn't marked const, which it probably should be. Adding the const specifier produces a compiler error (about ambiguous function calls), as it should.

Technically, we need only D8653 or this change to fix bug 386388. Do we still want this change?

I know that there is a problem, see the discussion on change D8634. The problem is that I'm not sure how to proceed: when do we encounter Utils::Other, and what do we do about it? The Clang Parser can probably not parse a file of type Utils::Other anyway.

I'm going to address the comments I didn't reply to.

The discussion is getting really nasty and I don't think it leads anywhere.

In D8211#157186, @kossebau wrote:

And "more advanced rendering code" still makes sense in an integrated development environment, at least to me, I see rendering power orthogonal to being part of IDE. Actually I consider a separate general browser application an inferior solution, as it does not allow to be properly integrated into kdevelop project/session management (project/session specific bookmarks, browsing history, tight control about location in UI etc).

If you run arc patch D8317 locally, you should get the commit with all necessary information, including my email address.

I don't have commit access yet, so could you commit this for me?

Added language flag for Objective C.

In D8211#154109, @rjvbb wrote:

I tested the build using WebKit as the backend with and without my patch (not with the very latest version) and didn't notice any difference. I do notice that it won't follow most (if not all) links in the documentation (also without my patch), is there something wrong with my build there?

In D7745#146271, @rjvbb wrote:

Seriously, how many of us use KDevelop to work on projects the size of GCC or llvm and need dirwatching on the whole tree? How expensive is that on Linux, *after* the initial import?

Watching directories is quite essential when working with Git or other SCMs. When checking out another branch, I want KDevelop's file tree to be updated as well.

Thanks!

I see you already submitted the change, but you omitted --sort=name.

Fix commit message and indentation.

Changed license to MIT.

I don't have a commit account, so I'd need you to commit the changes.

There are screenshots of other (known) syntax highlighters for Metamath on their homepage.

In D6184#123281, @rjvbb wrote:

I'm beginning to understand the objections from X11 users. Even with my settings horizontal scrolling behaves as if it's configured to scroll at least half the viewport width at a time. On Mac/Cocoa, horizontal and vertical scrolling are equally smooth, and that's where I did most of my testing (while replying to this ticket).