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).

In D6184#122970, @rjvbb wrote:

In these cases you don't want horizontal scrolling, because it destroys the alignment that helps the user orient. Which is especially important in source code, or a directory tree.

?? Who said my change implements per-line scrolling? The whole view is scrolled, just like in a text view where alignment is also not "destroyed" as you claim. Wrapping is much more detrimental to orientation.

Just my two cents: I work with a touch pad most of the time and wouldn't like horizontal scrolling in the project manager. The problem is that it wobbles left and right when all you want is to scroll up and down. I'm also not using it in the source code view, instead the dynamic word wrap helps me to break long lines, if they occur.

If anyone cares, here is what the official documentation says on this matter. I want to address the -std= vs. -cl-std= issue in another commit.

@apol: Could you have a look again? I think there is nothing wrong here.

By the way, I posted the question to Khronos. Their preferred channel seems to be opening an issue on one of their GitHub repositories. So I opened issue #27 at the OpenCL Registry. However, I do not expect an answer. From Khronos' point of view OpenCL source code is just a string in memory. Compiling OpenCL directly from file is not possible. (As far as I know the API.)