1. 13 Feb, 2018 1 commit
  2. 06 Feb, 2018 1 commit
  3. 05 Feb, 2018 1 commit
  4. 02 Feb, 2018 1 commit
  5. 18 Jan, 2018 3 commits
  6. 16 Jan, 2018 6 commits
  7. 15 Jan, 2018 1 commit
    • Dan Weatherill's avatar
      work around bug in kLineEdit · e6ee67c2
      Dan Weatherill authored
      Summary:
      a bug in kLineEdit causes spurious emission of textEdited signals when calling setText().
      
      This in turn causes spurious calls of compilerEdited() when selecting a compiler in the compilers window,
       which leads to a segfault (e.g. this bug https://bugs.kde.org/show_bug.cgi?id=373004) and I think some duplicates also.
      
      I have submitted also a patch to kcompletion, https://phabricator.kde.org/D9808
      
      This is a workaround for those systems until that is fixed
      
      Reviewers: #kdevelop, apol, mwolff
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: mwolff, anthonyfieroni, kdevelop-devel
      
      Tags: #kdevelop
      
      Differential Revision: https://phabricator.kde.org/D9809
      BUG: 373004
      FIXED-IN: 5.2.2
      e6ee67c2
  8. 10 Jan, 2018 2 commits
    • Milian Wolff's avatar
      Cache ProblemPointers per translation unit · f2a6941e
      Milian Wolff authored
      Summary:
      For visibility purposes, all 'inclue file not found' errors are
      associated with all files in a TU, since these usually completely
      break the interpretation of a file. But in some situations, this
      triggers a severe performance degradation:
      
      When the TU has a deep include stack depth and a file is not found
      somewhere at the bottom of the stack, then it will have one child
      diagnostic for every "included from ..." file higher up in the stack.
      Now if we would repeatedly build and intern the KDevelop::Problem
      representation for these diagnostics, for every file in the TU, we
      sometimes ended up spending *minutes* to create all the problems
      in ParseSession::problemsForFile!
      
      To workaround this situation, cache the ProblemPointer in the
      ParseSessionData for a given translation unit. This way, we will
      only convert a given diagnostic and its child diagnostics once per TU
      instead of once per file contained in a TU.
      
      In my case this brings down the time spent in problemsForFile for a
      single TU from ~7min (sic!) down to ~12s. While the latter is still
      a lot, this is already much more bearable.
      
      BUG: 386720
      
      Reviewers: #kdevelop
      
      Subscribers: kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D9772
      f2a6941e
    • Laurent Montel's avatar
      Remove unused file · 3881efbd
      Laurent Montel authored
      (cherry picked from commit d212fa1d)
      3881efbd
  9. 09 Jan, 2018 3 commits
    • Milian Wolff's avatar
      Format comments before setting them on the DUChain · 9761e029
      Milian Wolff authored
      Summary:
      This removes the /// and /* ... */ prefixes. Not only does this
      make the stuff way more readable, it also fixes our JSON tests...
      
      Return proper non-C++ specific includes/defines for non-project files
      
      When we query the includes/defines for a file outside of any project
      we always returned the C++ compiler includes/defines. This was because
      we never tried to guess the language type then, since we operated only
      on ProjectBaseItems pointers which are obviously nullptr for files
      outside of any project. Instead, operate on QString path
      representations like elsewhere in the IADM already. This allows us to
      guess the language type even for C, ObjC and Cuda files when they are
      not part of a project.
      
      No unit test is added, but I found this while working on a separate
      feature that has a proper unit test attached.
      
      Handle _Complex types
      
      We just create a delayed type that holds the string representation.
      This is enough to get the type displayed in the tooltips and it also
      removes the pesky warnings from the command line about unhandled
      types.
      
      Subscribers: kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D9472
      
      (cherry picked from commit 96b95928)
      9761e029
    • Milian Wolff's avatar
      Format comments before setting them on the DUChain · 2f2ac007
      Milian Wolff authored
      This removes the /// and /* ... */ prefixes. Not only does this
      make the stuff way more readable, it also fixes our JSON tests...
      
      (cherry picked from commit c31f2027)
      2f2ac007
    • Milian Wolff's avatar
      Set toolbar/toolbutton font on quickopen line edit · 56416bdd
      Milian Wolff authored
      Summary:
      The quickopen line edit is shown in the toolbar and thus should
      follow the font style of the other tool bar actions. So far,
      it did not do that. Now we manually force the toolbar font to
      ensure the font style is homogeneous.
      
      Subscribers: kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D9481
      
      (cherry picked from commit d0705822)
      56416bdd
  10. 06 Jan, 2018 1 commit
  11. 01 Jan, 2018 1 commit
  12. 11 Dec, 2017 1 commit
  13. 10 Dec, 2017 2 commits
  14. 09 Dec, 2017 1 commit
  15. 08 Dec, 2017 1 commit
  16. 06 Dec, 2017 1 commit
  17. 04 Dec, 2017 1 commit
  18. 27 Nov, 2017 3 commits
  19. 22 Nov, 2017 5 commits
    • Friedrich W. H. Kossebau's avatar
    • Kevin Funk's avatar
      cvs: Fix porting bug in QDir usage · 8622a1bc
      Kevin Funk authored
      QDir::absoluteDir() does always return a QDir instance pointing to the
      file's path *not including the file name*. Very bad API... That's not
      what we want here. We'd like to have the exact same path.
      
      A similar patch has been made in the Git plugin a while ago, see:
      623fe183
      8622a1bc
    • René J.V. Bertin's avatar
      kdevelop: prevent empty dockwidget context menuitems · f4363a08
      René J.V. Bertin authored
      Summary:
      This patch prevents dock widgets (toolviews) from having empty items in their context menus. Most the corresponding actions can probably not be represented in menus anyway and are thus unlikely to do anything when triggered through a menu. The average user doesn't know that though.
      
      The patch achieves this by filtering out QActions that would not have a title in `IdealDockWidget::contextMenuRequested()` but also adds a menu item text to two actions which I think make sense to include in the context menu. (Doing this makes it possible to hide the toolview's toolbar in more situations, gaining a bit of vertical space.)
      
      BUG: 386911
      FIXED-IN: 5.2.1
      
      Test Plan:
      Works as intended on Mac and Linux/X11 .
      
      I understand there may be another way to detect QActions that cannot be represented in menus but haven't yet found such an alternative. Such an alternative could be used in addition to the empty text check which I think should be done as argued in the summary.
      
      Individual plugins can also override `IToolViewFactor::contextMenuActions()`.
      
      Reviewers: kfunk
      
      Reviewed By: kfunk
      
      Subscribers: kdevelop-devel
      
      Tags: #kdevelop
      
      Differential Revision: https://phabricator.kde.org/D8954
      f4363a08
    • Kevin Funk's avatar
      cvs: Use K_PLUGIN_FACTORY_WITH_JSON properly · 9bd590c5
      Kevin Funk authored
      9bd590c5
    • Kevin Funk's avatar
      test_docker: Prefer QVERIFY over Q_ASSERT · 527cffd9
      Kevin Funk authored
      527cffd9
  20. 21 Nov, 2017 3 commits
  21. 19 Nov, 2017 1 commit
    • Milian Wolff's avatar
      Don't add the same targets multiple times for nested CMake projects · c2f9b5f2
      Milian Wolff authored
      When we import a cmake project folder and that contains nested
      CMake projects, we ended up showing the same target multiple times,
      since the CMake server output will reference the same targets for
      the parent project and then again for the nested project(s).
      
      Ensure the targets are only added once to fix this issue.
      
      BUG: 387095
      c2f9b5f2