- User Since
- Apr 16 2015, 7:53 PM (157 w, 5 d)
Mon, Apr 23
@brauch did you notice any issues? if not, can you accept this then I'll push it.
Sun, Apr 22
To query what include files you got, the easiest really is to define the KDEV_CLANG_DISPLAY_ARGS=1 env var. Then you'll see the command line we use for libclang, which includes the include paths. Defines could be queried by setting KDEV_CLANG_DISPLAY_DEFINES=1.
Thu, Apr 19
Very good. Now I'd like to get some feedback from @apol to see how this works with his android toolchain. I'll also test this later with an arm toolchain and see if it works as expected.
Wed, Apr 18
Everyone, please test https://phabricator.kde.org/D12331
Done, Rene - feel free to respin with the issue fixed.
Let's revert and then we can fix it later. This patch is imo less important than a working generic manager. I'll apply the revert now.
ok let's see
Tue, Apr 17
I'd appreciate if others could give this a spin and report back whether it is improving things or not.
Mon, Apr 16
There's qdoc, doxypress, proprietary custom formatting styles... Comments are free form after all, anything might be in there.
Ping? Or can I just commit?
I'm very unsure about this. On one hand, this obviously looks better in your screenshots. On the other hand, what if we encounter comments that are formatted with some other syntax? Most notably consider how your code would lead to broken HTML quite easily, e.g. when only part of a match is encountered (such as only \f\[ but no \f\]).
Fri, Apr 13
Tue, Apr 10
some nits, otherwise lgtm assuming all tests pass
Mon, Apr 9
Fri, Apr 6
fix a corner case where we miscalculated the inPrefixPath
Thu, Apr 5
ok, let's go for it then
Wed, Apr 4
I'll push this to master then and we can cherry pick it to 5.2 after you guys did the next release
should it go to master, or 5.2? @brauch, @kfunk? I'd like others to test this too first before landing in 5.2, since I've never used CMAKE_CACHEFILE_DIR before and am not sure if it's OK to use it like this.
remove unrelated changes (oh how I hate arc)
add a comment explaining why this happens, but otherwise lgtm
Tue, Apr 3
the "also" in your commit message: can you split this commit into two parts, or is the feature addition also fixing the bug? Put differently: Could you first fix the bug, then add the feature, in separate commits?
instead of duplicating it further, could we move the code into ktexteditor and make it reusable from there?
maybe instead make it explicit what the old code did instead? i.e. check what you get from GCC for "1 << -1" and then use that when i == 0
Ah, I knew it :D I suspected missing compiler optimizations from the start... But tricky indeed for you to see!