I've just stumbled into a case where I would need -stdlib=libc++, which this change would solve.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Oct 9 2019
I still think this is the right change, but if there is no consensus I will implement @mwolff's suggestion. That would certainly be an improvement, but it doesn't really solve my problem. I'm currently working on Clang and have around 6 files open, which is really not a lot. I haven't changed any of them. The result:
Jul 20 2019
In D22182#495823, @mswan wrote:Also, in spite of what I said earlier, I think the explicit DUChain locking should be done and there eventually should be some work done to determine which objects will only interact with one specific DUChain per instance of that object, i.e. an object that should reference a specific DUChain, e.g. ClangSupport. We could make the first pass at this involve replacing all of those DUChainReadLocker lock; lines with DUChainReaderLocker lock(DUChain::lock());, [...]
Overall I think this is a good idea, although we need to figure out some details. Could you either remove commented out flags or add a comment why we have them (commented out)?
I don't know what would be required to support multiple DUChains, but it seems plausible that they can be locked separately. In this case it would help to have the explicit argument, I guess. It could even be inevitable, when there is no single global DUChain anymore.
In D22559#498026, @kfunk wrote:I do not think bumping versions "just because " has any value.
Jul 10 2019
Jul 8 2019
In D22182#492087, @mswan wrote:The workaround being that we eliminate the try-lock behaviour in our locker constructors and move that timeout behaviour elsewhere?
Exactly.
Jul 7 2019
In D22182#491716, @mswan wrote:I don't suspect our ..Locker constructors will ever (i.e. not anytime prior to the heat death of the universe) take a different lock. For that reason I am partial to making the lock implicit wherever possible.
That's a bold statement. ;)
Jul 4 2019
In D22182#490537, @mswan wrote:I have actually tried changing my experiment with clang's thread safety to use the scoping feature and I seem to be seeing a new issue with these destructors with an error like "lock using shared access, expected exclusive access."
EDIT: I have come across your oldish ticket regarding this: https://bugs.llvm.org/show_bug.cgi?id=33504. Evidently I need to annotate my DUChainReadLocker releasing functions with RELEASE(..) instead of RELEASE_SHARED(..). Not sure I understand why.
In D22182#490534, @mswan wrote:I agree, but in the current implementation they are see DUChainReadLocker::lock() and DUChainReadLocker::unlock(), they both check if we are already locked before continuing to lock or unlock respectively.
In D22182#490532, @mswan wrote:Interesting. I have experimented with this a bit and I cannot find a way to articulate to the thread safety system that my lock and unlock functions are idempotent. If I call lock.unlock() and later return without locking it again, I get a warning (or rather an error because I set -Werror=thread-safety) that complains that I am releasing a lock that isn't held. So would -Wno-error=thread-safety-negative allow us to get around that or is there possibly some other solution?
In D22182#489873, @mswan wrote:This should definitely be tried and I would be interested in the task. There is definitely quite alot of stuff that needs to be annotated to make this work so it might need several hands working on it.
Jul 3 2019
I looked through all of the paths to the failed assertion discussed in that latter ticket and it appears that all but the invocation in PotentialBuddyCollector::accept is verified to have the reader lock held prior to invocation. There were two paths which needed a lock added given my change, so this change set should not cause any regression on bug #386901.
Feb 14 2019
In D18551#411905, @rjvbb wrote:Indeed, and in that light clang's solution is maybe not that smart, at least not for use as a parser for an entire project. From what I understand that preamble is just a precompiled header file, which in my experience can be tricky to set up (typically require some sort of central header that imports everything that'll be needed everywhere). Having one such preamble per file cannot but duplicate lots of data.
You're right, it's a precompiled header file. I think it works very well for the intended purpose: quick reparsing on most user edits. The additional option that we use here was added in https://reviews.llvm.org/D15490 for pure code completion workloads. I don't think it's meant for us, even though we do completion as well: we also build an index, and have possibly many more files open.
In D18551#411309, @rjvbb wrote:Well, if among developers you cannot find a solution that covers all use cases a configurable setting (applying only to setting the preamble-on-first parse flag or not) could well be the only compromise.
I wouldn't want to give up on a consensus just yet. I think the Clang developers have actually chosen a pretty smart default, and this additional flag incurs costs that are hard to control for hardly any benefit.
Feb 13 2019
In D18551#410396, @rjvbb wrote:Or, you add a flag to one of the relevant settings panels. There are already a number of options that aren't exactly easy to understand for everyone, this one could be something like "Make code-completion results available faster (can require significant resources)".
Feb 11 2019
In D18551#409551, @mwolff wrote:When we didn't create the preamble, we will have to reparse the file completely. And this can easily take 1-2s per file, which is *really* annoying.
It only happens on the very first edit though, and will only be noticeable if code completion is required immediately after starting to edit the file. All following parses and code completions can use the precompiled preamble then. I don't think that's too bad. It's also not unusual, many applications have something like a "warmup phase" where not everything is loaded yet.
Feb 6 2019
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?
Feb 5 2019
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.
Feb 3 2019
In D18551#404077, @rjvbb wrote:If line 3 means "files opened after (1)" then yes, that's probably correct.
Feb 2 2019
The way I understand it, the proposals are slightly different. Maybe we can summarize them as follows:
Feb 1 2019
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.
Jan 31 2019
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.
Jan 29 2019
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.)
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.
Jan 26 2019
Wouldn't that be an opportunity to add the override specifier? The commit message could state "Fix function signature of ... to override".
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.
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.
Jan 25 2019
Jan 24 2019
In D17289#399019, @rjvbb wrote:If you don't use systemd, for example because you're not on Linux, there are certainly other tools for doing the same thing.
How does that systemd thing clean tmp dirs at runtime, IOW, how can it know it's safe to clean up a given file if the application that created it doesn't do something explicit to guarantee cleanup?
Jan 23 2019
In D17289#398555, @rjvbb wrote:In D17289#395491, @aaronpuchert wrote:Temporary files being left behind after a crash is not unusual. This is why systemd has systemd-tmpfiles --clean.
Not really relevant outside of the systemd realm, right? :)
Jan 17 2019
In D17289#370477, @rjvbb wrote:Actually, issues with clang temp files is why I started to think about this kind of change but ultimately I realised it didn't seem such a bad idea at all to put all KDevelop-related temporary files in a dedicated location. I often clean out a bunch of KDevelop's own temp files that were left behind, e.g. after a crash. I just didn't mention them because they're negligible in size (and I purge before their numbers really start to grow).
Dec 10 2018
Nov 18 2018
Nov 14 2018
In D16218#346296, @rjvbb wrote:Maybe you can add an else branch where you re-raise the signal with the default handler.
If the goal is just to let a 2nd signal trigger the default reaction from the runtime then it can be even simpler.
Oct 20 2018
Thanks for the quick review!
The signal handling and processing gets a +1 from me, but someone else should review the overall code structure.
Oct 19 2018
Oct 18 2018
In D16218#345150, @rjvbb wrote:So is it enough to change to std::atomic_flag or should we use some sort of critical section with an actual lock? Because for handlingSignal that's possible as it is outside of the actual signal handler.
Oct 17 2018
In D16218#344435, @rjvbb wrote: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.
But is it always lock-free on the relevant architectures? Or rather:
- what determines if the type is lock-free
- what are "the relevant architectures"?
Oct 16 2018
You're right, my remarks apply to the existing code already.
Oct 15 2018
Oct 4 2018
Don't we know the exact version of Clang at compile-time when building the bundled version? I think this change is mainly interesting for the "unbundled" case when Clang can be updated independently. Or what am I missing?
Oct 3 2018
In D15895#335917, @buschinski wrote:"cpuid.h" on my system is in:
- /usr/lib64/clang/7.0.0/include/cpuid.h
$ llvm-config --libdir
/usr/lib64/llvm/7/lib64
Oct 2 2018
@kossebau Are you Ok with this change? I'm not sure I'll get a review from the domain experts, but I'm fairly confident now that the changes are right.
In D15694#333087, @rjvbb wrote:My point here was that making a whatever-you-call it more or less obligatory in something that is (used to be) shared with a closely related language introduces unnecessary confusion ("wait, am I writing C or C++ here"). And extra overhead when reusing algorithms between those languages.
Sep 27 2018
Attributes are not keywords — they're a (C++-specific) generic syntax that was introduced with C++11. There are numerous compiler-specific attributes, usually prefixed with the compiler name, and some standardized attributes. See cppreference.com for a list of those.
In D15694#330932, @rjvbb wrote:My gripe is more with having to change my habits in ways I don't necessarily agree with entirely, and which might interfere with coding in other contexts.
It may not in KDevelop's code, but that's not all that all of us work on. Coding style and guidelines for KDevelop itself could reflect good practice you'd like to advocate in general.
Given that languageOption also has Q_UNREACHABLE(), and both are always called together, any crash that could happen would have already happened before. The function is called from CompilerProvider::{defines,includes} and both catch the Other case before calling into the ICompiler implementation. Maybe we should document the constraint (type != Utils::Other) in the ICompiler interface, but we should do it in a separate commit.
Sep 26 2018
I didn't test it, but it looks fine to me.
So I think there are two questions to decide here:
- Do we want a -std= flag, does Clang even accept that?
- Should we just take the ObjC flags from the C flags, and ObjC++ flags from the C++ flags, or should they be set independently?
Sep 23 2018
After testing the GitHub provider and the QmlJS code completion I'm somewhat confident that these changes are correct, but I want to give the experts on that code a chance to weigh in before I merge this. Now onto the discussion.
In D15694#330687, @rjvbb wrote: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.
Remove comment in plugins/ghprovider/ghproviderwidget.cpp, as the fallthrough is probably intended, and add break in plugins/qmljs/codecompletion/context.cpp, as it is probably not intended. Now the code completion doesn't suggest variables of the same type as the last parameter in functions calls, which seems about right.
In D15694#330503, @kossebau wrote:Yes, needs to be included for such source file, because the min Qt dependency version is still 5.5, and Q_FALLTHROUGH was only introduced in 5.8 (see note at http://doc.qt.io/qt-5/qtglobal.html#Q_FALLTHROUGH)
Sep 22 2018
In D15532#330269, @rjvbb wrote: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...
There are two suspicious fallthroughs, maybe someone with a better understanding than me can comment on that.
In D15532#330024, @rjvbb wrote:I prefer to remind myself of such things and that I'm putting it there anyway (because the compiler won't be able to tell me I really forgot to use one, not unless you make some kind of "no break here" statement obligatory).
Sep 21 2018
In D15530#329377, @rjvbb wrote:You should probably also add a few lines to the custom-definesandincludes plugin.
In a different review I presume?
In D15532#329308, @rjvbb wrote:We could activate -Wunreachable-code so the compiler tells you where break isn't needed.
Evidently I was talking about a general principle, not about introducing a dependency on the compiler telling you what (not) to do. If I wanted that I'd be coding in Modula-2 ...
You should probably also add a few lines to the custom-definesandincludes plugin.
Aug 24 2018
In D14931#314739, @vkorneev wrote:I was in doubt between these two variants while writing the code and stopped on current one for two reasons:
- Looking at QT source code, reset() is ultimately reduced to QSharedPointer copy(t); swap(copy); anyways. And QSharedPointer has move constructor, so it'll work in this case (right?).
- Current variant better expresses my intentions (that's subjective). But if you still think that we should use reset() I'd change it in a moment. What do you think?
Aug 23 2018
Aug 13 2018
Ok, I take it that space optimizations could also be done later if necessary. I will merge it then after correcting the comment.
Aug 10 2018
Do you have commit access or should I commit this for you?
Otherwise it's fine.
Aug 9 2018
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
Aug 8 2018
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.
Aug 7 2018
Maybe you can also activate the warning (as error) in CMakeLists.txt?
Aug 6 2018
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.