1. 03 Dec, 2020 1 commit
  2. 02 Dec, 2020 4 commits
    • Milian Wolff's avatar
      Don't warn about potentially unused function · 0e1838c9
      Milian Wolff authored
      It's used in debug builds
    • Milian Wolff's avatar
      kdev-clang: selectively apply ForceUpdate to the requested document · 8edea338
      Milian Wolff authored
      When we get a parse job with the ForceUpdate flag set, we used to
      apply this flag to all imports. So basically ForceUpdateRecursive
      and ForceUpdate where handled in the same way, which is obviously
      not a good idea.
      Instead, track the document for which the parse job got created and
      only apply ForceUpdate to that one.
      This greatly improves the performance of reparsing after switching
      git branches or using git stash: These actions would always trigger
      a document reload and a parse job is created with ForceUpdate set.
      Previously, this then meant that we reparsed all imports too. For
      files with many imports, this was extremely slow and totally unneeded.
      As an example: Editing heaptrack's accumulatedtracedata.cpp and then
      applying `git stash` tackes ~34s on my machine before this patch. With
      this patch, it only takes ~200ms instead.
    • Milian Wolff's avatar
      kdev-clang: properly track modification revisions of imported files · ef28c644
      Milian Wolff authored
      The previous code only ever tracked the the modification revision
      of a file itself, but not of the files it imported. Now, we actually
      do that, which ensures we automatically reparse a file when one of
      its imports has changed.
    • Milian Wolff's avatar
      Use QFileInfo::canonicalFilePath instead of QDir::canonicalPath · e8923578
      Milian Wolff authored
      The path is to a file, not to a dir, so it's pretty odd that we
      used QDir here.
  3. 28 Nov, 2020 4 commits
  4. 22 Nov, 2020 1 commit
  5. 20 Nov, 2020 1 commit
  6. 17 Nov, 2020 1 commit
  7. 16 Nov, 2020 1 commit
  8. 15 Nov, 2020 4 commits
  9. 14 Nov, 2020 4 commits
    • Igor Kushnir's avatar
      Make all DUChainReferenceCounting globals thread_local · 3c7257e5
      Igor Kushnir authored
      Move the variables into a simple new DUChainReferenceCounting class to
      avoid the repetition of the `thread_local` keyword.
      Reorder the declarations and initializations of two variables -
      refCountingHasAdditionalRanges and refCountingRanges - to minimize
      sizeof(DUChainReferenceCounting) while preserving the logic of the
      variable ordering and grouping within the class.
      Eliminate the mutex and the redundant dependency between threads.
      This should work perfectly if the reference counting of each object is
      confined to a single thread. This will break code that calls
      DUChainReferenceCounting functions on the same object from multiple
      threads. Hopefully such code does not exist.
      This change does not break any kdevelop or kdev-python tests.
    • Igor Kushnir's avatar
      Make the global variable doReferenceCounting thread_local · db67d592
      Igor Kushnir authored
      This variable is accessed concurrently from multiple threads. It is
      written to under a mutex lock, but read from without any thread
      synchronization. Therefore the variable has to be either atomic or
      thread_local to prevent data races.
      As far as I can tell, the variable's value is never intended to be
      shared with other threads. If one thread temporarily sets
      doReferenceCounting to true, and then another thread reads the variable
      before the first thread resets it to false, there is redundant mutex
      locking. If this other thread then (redundantly) sets
      doReferenceCounting to true, performs some operation and resets it to
      false; then the first thread reads this variable again, some necessary
      checks and steps can be skipped in the first thread. So thread_local
      seems to be the more correct and performant alternative.
      This change does not break any kdevelop or kdev-python tests.
    • Igor Kushnir's avatar
      Use std::as_const in place of custom make_const · 46158d1a
      Igor Kushnir authored
    • Bernd Buschinski's avatar
      Fix excessive KPassivePopup usage in case of debugger errors · 8fca91a0
      Bernd Buschinski authored
      - Group duplicate error messages
      - Port to KNotification
      - This fixes a kwin_x11 crash for some X11 drivers
  10. 11 Nov, 2020 1 commit
  11. 10 Nov, 2020 1 commit
  12. 09 Nov, 2020 1 commit
  13. 07 Nov, 2020 1 commit
  14. 05 Nov, 2020 1 commit
  15. 04 Nov, 2020 4 commits
  16. 01 Nov, 2020 2 commits
  17. 30 Oct, 2020 8 commits
    • Milian Wolff's avatar
      Simplify manpagemodel and prevent leaks in test · 353a86e3
      Milian Wolff authored
      Most notably, don't use a heap-allocated QListIterator, that's just
      insane. Use a plain int to index into a vector, which is much much
      more efficient.
      Also simplify the test to ensure it properly awaits the load-or-error
      case properly.
    • Milian Wolff's avatar
      Actually ensure that the test_qthelpplugin sees some data · 6ff9410a
      Milian Wolff authored
      The qmake process is run asynchronously, so we have to wait for
      the data in the test, otherwise it will just skip right through
      most of it...
    • Milian Wolff's avatar
      Don't leak QProcess in QtHelp plugin · ba180bb3
      Milian Wolff authored
      This actually shows that we are destroying the plugin repeatedly
      before the process finishes, which means the slot gets disconnected
      and never delets the process...
    • Milian Wolff's avatar
      Port private slot to lamda · 24e0750a
      Milian Wolff authored
    • Milian Wolff's avatar
      Fix indentation and add non-inline dtor · fa62c04c
      Milian Wolff authored
    • Milian Wolff's avatar
      Don't leak deleted breakpoints · 5eeedbe5
      Milian Wolff authored
      But really, this is just a stop-gap measure to
      prevent LSAN reports in the unit test. We still
      basically leak the deleted breakpoints until we
      destroy the model, so nothing really is won here.
      But it seems like the whole ownership and lifetime
      tracking of breakpoints is utterly broken. Note how
      we store e.g. raw pointers in the breakpoint controller
      and don't seem to clean those up ever properly either...
    • Milian Wolff's avatar
      Explicitly disable sanitizers for debuggees · 927b758b
      Milian Wolff authored
      I often just set CMAKE_CXX_DEBUG_FLAGS to contain
      `-fsanitize=address,undefined` which would then influence the
      observed behavior of the debuggees in test_gdb and lead to
      failed tests.
      Instead, explicitly disable the sanitizers to make sure we don't
      run into this corner case.
    • Milian Wolff's avatar
      Don't leak QProcess in DebugSession::execInferior (remote debugging) · d9782419
      Milian Wolff authored
      Fixes LSAN report:
      Indirect leak of 16 byte(s) in 1 object(s) allocated from:
          #0 0x7fbbce16ef41 in operator new(unsigned long) /build/gcc/src/gcc/libsanitizer/asan/asan_new_delete.cpp:99
          #1 0x56469f8deab5 in KDevMI::GDB::DebugSession::execInferior(KDevelop::ILaunchConfiguration*, IExecutePlugin*, QString const&) /home/milian/projects/kf5/src/extragear/kdevelop/kdevelop/plugins/gdb/debugsession.cpp:217
          #2 0x56469fa482f2 in KDevMI::MIDebugSession::startDebugging(KDevelop::ILaunchConfiguration*, IExecutePlugin*) /home/milian/projects/kf5/src/extragear/kdevelop/kdevelop/plugins/debuggercommon/midebugsession.cpp:284
          #3 0x56469f81ef97 in KDevMI::GDB::GdbTest::testRemoteDebug() /home/milian/projects/kf5/src/extragear/kdevelop/kdevelop/plugins/gdb/unittests/test_gdb.cpp:1658