> On Jan 7, 2019, at 16:14, Jason H <jh...@gmx.com> wrote: > > Can someone explain to me what the LanguageServer addition ( > https://bugreports.qt.io/browse/QTCREATORBUG-20284 ) might do for this? I > woud think it would help?
In the future some time maybe. The protocol itself still has some way to go. Currently it e.g. doesn’t provide any highlighting (though it is in the works). See e.g. this list from Clangd https://clang.llvm.org/extra/clangd.html#current-status about what does and does not come with LSP. Two prominent server implementations for C++, Clangd and cquery are based on libclang, so I’d expect some of the issues that we have (like with parsing some Windows headers, file locking, getting it to use the right compiler options, parsing speed) will simply be the same. There is also the language server from Microsoft itself, one could hope that that works better with MSVC based code ;) > I too have noticed QtC's recent versions slowing down. I used to think it was > a cool add, but it's starting to get in the way. OR it could be that my > expectations have increased and I rely on it more whereas it as a > nice-to-have. But the slowdowns remove the value added. Please definitely make sure that you use a configuration that does not include any clang-tidy checks (Options > C++ > Code Model). Any of these check should be considered “optional, only enable if they do not degrade performance for you”. I fell into the same trap recently, so I wonder what we could do to provide users with better hints when this happens? > However I can put up with the slowdown a lot easier than help not working. At > this point, if it starts with a 'Q', F1 should just open a webview to the > online documentation because the built in help will not likely work. I agree that when the code model based lookup fails, it should try a purely word based lookup. This should work whenever you ask for help on a type name, and even in case of method names which might not be uniquely identified we can still ask. We do it for the help locator filter (type ctrl+k + “? something” (cmd+k on macos)). > > I think we're coming to a point where Qt is getting too many features that > don't work and is hurting rather than helping. Maybe these things can be > fixed in a Z release, but I suggest focusing on getting 4.8 right before > adding any more features. I don't know what's scheduled for 4.9, but the FF > is supposed to be Feb 5. > > > > Sent: Sunday, January 06, 2019 at 1:20 PM > From: "BogDan Vatra via Qt-creator" <qt-creator@qt-project.org> > To: qt-creator@qt-project.org, "Michael Jackson" > <mike.jack...@bluequartz.net>, "NIkolai Marchenko" <enmarantis...@gmail.com>, > qt-creator <qt-creator@qt-project.org> > Subject: Re: [Qt-creator] Qt creator + Clang model = major annoyance > Hi, > > It's not QtCreator fault, it's clang which can't compile fast enough your > file. The only hope for a faster clang code model is this > https://reviews.llvm.org/D52193 patch. IMHO TQC and everyone who uses clang > code model should do everything they can to help, review and merge that patch. > > Cheers, > BogDan. > > > On January 6, 2019 7:55:41 PM GMT+02:00, Michael Jackson > <mike.jack...@bluequartz.net> wrote: > On some points I agree, but being on macOS my choices are pretty limited for > an IDE. xCode? Uh no. Eclipse? No way. What else is there? QtCreator is > pretty much the only choice I have. I am hoping that the QtCreator team can > carve out some time in 2019 to look into some of the speed issues with the > clang backend. > > > Frankly my issue with the old parser was _because_ of boost. The original > code model would _never_ want to parse our use of boost which made code > completions pretty non-existent in our boost heavy code. When the CCM > successfully parses the file the complete is spot on, it just takes forever > to parse the code. One thing that I have noticed is that if I turn off all > the clang-tidy and clazy checks then the speed on first opening is pretty > decent (I’m on a 2012 Mac Pro with dual Xeon so not the fastest CPUs in the > world). If I turn on the clang-tidy checks that I want then the time to get > even the function list is abysmal. I would think a 2 stage parse of the file > might work better with 2 threads: 1 for the initial parser and one for the > clang-tidy checks. Waiting 30 seconds (or sometimes never) for a function > list to appear seems like a deficiency in my mind. > > > Again, I really appreciate how far QtCreator has come from the “old days” in > the 2.x versions. I have used it through the 1.5 years of “dark ages” where > debugging on macOS was basically non-existent due to LLDB being so immature. > QtCreator works way better with our CMake heavy projects and all of the > external libraries that we used. I think it just needs some polish on the CCM > parsing and reaction times put into it in 2019. > > > -- > > Michael Jackson | Owner, President > > BlueQuartz Software > > [e] mike.jack...@bluequartz.net > > [w] www.bluequartz.net > > > > On 1/4/19, 8:20 PM, "Qt-creator on behalf of NIkolai Marchenko" > <qt-creator-boun...@qt-project.org on behalf of enmarantis...@gmail.com> > wrote: > > > Qt creator is rapidly becoming a source of major annoyance ever since clang > code model was introduced. > > > It's slow, sometimes taking 30+ seconds to react to F2 > > What's worse, it reacts to it once you gave up and navigated somewhere > manually and makes you suddenly type stuff in plces you won't expect. > > > It's buggy, fails on boost and fails to produce a highlight on everything > that depends on it > > > It's too easy to break, A single symbol it doesn't detect breaks highlighting > and hint for the whole file chain, whether stuff later down the line requires > that symbol or not. > > > While I understand the desire to stop reimplementing the wheel with code > parser, the Clang Code Model made Qt Creator strictly worse for any complex > project to the point I catch myself wanting to use something else on a > regular basis. This wasn't the case ever before CCM was introduced. > > _______________________________________________ Qt-creator mailing list > Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator > > > -- > Sent from my Android device with K-9 Mail. Please excuse my > brevity._______________________________________________ Qt-creator mailing > list Qt-creator@qt-project.org > https://lists.qt-project.org/listinfo/qt-creator > _______________________________________________ > Qt-creator mailing list > Qt-creator@qt-project.org > https://lists.qt-project.org/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
