1. 25 Sep, 2017 1 commit
  2. 24 Sep, 2017 1 commit
  3. 23 Sep, 2017 1 commit
  4. 22 Sep, 2017 1 commit
    • Christoph Roick's avatar
      Revert automatic grep job execution from Find in Files history · b9904391
      Christoph Roick authored
      Summary:
      - raise of output view is suppressed for jobs from history
      - only search parameters are displayed, actual search can be
        redone with "Refresh"
      - population of list is still deferred until all projects
        are loaded to ensure correct display of search description
      
      BUG: 384899
      
      Test Plan:
      - on restart no search is performed, but can be triggered by "Refresh"
      - output view stays closed on startup
      
      Reviewers: #kdevelop, brauch
      
      Reviewed By: #kdevelop, brauch
      
      Subscribers: brauch, kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D7945
      b9904391
  5. 21 Sep, 2017 10 commits
    • Kevin Funk's avatar
      Merge remote-tracking branch 'origin/5.2' · a0e154da
      Kevin Funk authored
      a0e154da
    • Francis Herne's avatar
      Remove extra parens · ac0ef9f3
      Francis Herne authored
      Fixes compilation after f149bed1
      ac0ef9f3
    • Kevin Funk's avatar
      Merge remote-tracking branch 'origin/5.2' · 6a5193d9
      Kevin Funk authored
      6a5193d9
    • Kevin Funk's avatar
      Make compile for me · 604ff0dd
      Kevin Funk authored
      Issue:
      test_duchain.cpp:2055:69: error: parameter declarator cannot be qualified
      604ff0dd
    • Milian Wolff's avatar
      Workaround parse errors due to missing implementation of __has_include · f149bed1
      Milian Wolff authored
      GCC reports the following two defines as built-in:
      
      There are no definitions of __has_include{,_next}__ available in clang
      though, leading to parse errors like:
      
      2 problems encountered:
       "Function-like macro '__has_include__' is not defined" "" [ (1, 12)  ->  (1, 25) ]
       "Broken c++11 setup (__has_include)" "" [ (4, 9)  ->  (4, 14) ]
      
      This then propagates to all kinds of issues, most notably when parsing
      Qt headers. There, we suddenly fail to realize that the compiler is
      C++11 capable (__has_include(<atomic>) errors out), and more.
      
      Overall, the language parser is suddenly completely broken. We now
      catch these two function macros and skip them, to ensure they never
      override the builtin functionality of clang. This fixes the new unit
      test and also makes KDevelop behave properly again with newer Clang
      when parsing Qt 5 code bases.
      
      The question now is: Why do we use GCC by default to find the built-in
      defines? I thought we'd default to Clang since a long time by now...
      
      (cherry picked from commit ea3cb5a8)
      f149bed1
    • Milian Wolff's avatar
      Dump defines file when KDEV_CLANG_DISPLAY_DEFINES is set · 3516c318
      Milian Wolff authored
      We need to jump through some hoops here, since it's not easy
      to rewind the temporary file itself to have it output its contents.
      So instead, close the file and reopen it separate to read the
      contents.
      
      (cherry picked from commit bbc57107)
      3516c318
    • Milian Wolff's avatar
      Prefer the first available compiler as default compiler · 5d75d8d6
      Milian Wolff authored
      Commit 65106bec introduced this regression: The code used to
      return early when a compiler was found. The new loop to cache
      the result always iterates over all compilers.
      
      Essentially, this reverts the whole logic within the IDM: Instead
      of prefering, say, Clang over GCC, it actually does the opposite
      and will prefer GCC over Clang. This patch adds the missing break
      to restore the old behavior.
      
      This ensures we will once again use Clang instead of GCC by default
      for includes and built-in defines. As exemplified by the recent
      breakage (__has_include) when using GCC, and the history of the
      shaky GCC integration, this is important for a good default
      impression of KDevelop.
      
      (cherry picked from commit f6e3d8b9)
      5d75d8d6
    • Milian Wolff's avatar
      Prefer the first available compiler as default compiler · f6e3d8b9
      Milian Wolff authored
      Commit 65106bec introduced this regression: The code used to
      return early when a compiler was found. The new loop to cache
      the result always iterates over all compilers.
      
      Essentially, this reverts the whole logic within the IDM: Instead
      of prefering, say, Clang over GCC, it actually does the opposite
      and will prefer GCC over Clang. This patch adds the missing break
      to restore the old behavior.
      
      This ensures we will once again use Clang instead of GCC by default
      for includes and built-in defines. As exemplified by the recent
      breakage (__has_include) when using GCC, and the history of the
      shaky GCC integration, this is important for a good default
      impression of KDevelop.
      f6e3d8b9
    • Milian Wolff's avatar
      Workaround parse errors due to missing implementation of __has_include · ea3cb5a8
      Milian Wolff authored
      GCC reports the following two defines as built-in:
      
      #define __has_include(STR) __has_include__(STR)
      #define __has_include_next(STR) __has_include_next__(STR)
      
      There are no definitions of __has_include{,_next}__ available in clang
      though, leading to parse errors like:
      
      2 problems encountered:
       "Function-like macro '__has_include__' is not defined" "" [ (1, 12)  ->  (1, 25) ]
       "Broken c++11 setup (__has_include)" "" [ (4, 9)  ->  (4, 14) ]
      
      This then propagates to all kinds of issues, most notably when parsing
      Qt headers. There, we suddenly fail to realize that the compiler is
      C++11 capable (__has_include(<atomic>) errors out), and more.
      
      Overall, the language parser is suddenly completely broken. We now
      catch these two function macros and skip them, to ensure they never
      override the builtin functionality of clang. This fixes the new unit
      test and also makes KDevelop behave properly again with newer Clang
      when parsing Qt 5 code bases.
      
      The question now is: Why do we use GCC by default to find the built-in
      defines? I thought we'd default to Clang since a long time by now...
      ea3cb5a8
    • Milian Wolff's avatar
      Dump defines file when KDEV_CLANG_DISPLAY_DEFINES is set · bbc57107
      Milian Wolff authored
      We need to jump through some hoops here, since it's not easy
      to rewind the temporary file itself to have it output its contents.
      So instead, close the file and reopen it separate to read the
      contents.
      bbc57107
  6. 20 Sep, 2017 6 commits
  7. 19 Sep, 2017 2 commits
  8. 18 Sep, 2017 7 commits
  9. 17 Sep, 2017 2 commits
  10. 15 Sep, 2017 2 commits
  11. 14 Sep, 2017 5 commits
    • Friedrich W. H. Kossebau's avatar
    • Kevin Funk's avatar
      Merge remote-tracking branch 'origin/5.2' · 825adb1e
      Kevin Funk authored
      825adb1e
    • Kevin Funk's avatar
      Minor: Fix coding style · c917ebbe
      Kevin Funk authored
      c917ebbe
    • Craig Tenenbaum's avatar
      Type Alias Template fix · 54a8aa75
      Craig Tenenbaum authored
      Summary:
      Since Clang 3.8, libclang began exposing an `CXCursor_TypeAliasTemplateDecl` cursor as a result of work done by a KDevelop developer. Ironically, this feature was never actually integrated into KDevelop's clang support, and because of how cursors are dispatched in clang's DUChain builder, the default action is to recurse into any cursor enumeration not explicitly listed. This, in turn, recurses into `CXCursor_TypeAliasTemplateDecl`, and while that does eventually pick up a child `CXCursor_TypeAliasDecl` cursor, ensuring that the declaration is added to the DUChain, the foremost descendants of `CXCursor_TypeAliasTemplateDecl` tend to be template parameters, effectively leaking these parameters into the surrounding context.
      
      Moreover, since the addition of `CXCursorTypeAliasTemplateDecl`, references from `CXCursor_TemplateRef` point directly to these cursors which, unfortunately, have a spelling range which covers the `using` keyword that introduces the name which will refer to this alias, but not the name itself. Additionally, unlike `typedef` cursors or `CXCursor_TypeAliasDecl`, `CXCursor_TypeAliasTemplateDecl` yields no useful information about the type it is aliasing; interestingly, `CXCursor_TypeAliasDecl` provides this information without fault, even if it refers to templates with template parameters. Ultimately, this means that the actual `CXCursor_TypeAliasTemplateDecl` cursor, for the moment, is good for little more than signalling the beginning of a new context to capture template parameters and possibly new types, and the actual, declarative unit is still a `CXCursor_TypeAliasDecl` cursor. Sadly, this means the procedure for building uses from cursors needs to be tweaked so lookups will make the correct association (they presently do not). Ultimately, the real fix should be in investigating the upstream implementation of `CXCursor_TypeAliasTemplateDecl` to see if it can be made to function more like a traditional declaration cursor.
      
      BUG: 384580
      FIXED-IN: 5.2
      
      Test Plan: Modified extant testTypeAliasTemplate test in test_duchain-clang to verify this patch works as expected, namely, that it doesn't leak template parameters into the surrounding context, and that uses of the type alias template are correctly tracked in the DUChain. If you simply apply the changes to test_duchain.cpp on their own, the breakage of the current code model becomes apparent.
      
      Reviewers: #kdevelop, mwolff, kfunk
      
      Reviewed By: #kdevelop, mwolff
      
      Subscribers: apol, kdevelop-devel
      
      Tags: #kdevelop
      
      Differential Revision: https://phabricator.kde.org/D7799
      54a8aa75
    • Aleix Pol Gonzalez's avatar
      Make it possible for IBuildSystem to provide extra arguments to the parser · 0c05bd55
      Aleix Pol Gonzalez authored
      Summary:
      So far it was limited to defines and includes, but there's more to life
      than that.
      This implements it for cmake where I tested it most, also for qmake where
      I'm not sure how to yet it won't be worse than ignoring the variables.
      
      Reviewers: #kdevelop, kfunk
      
      Subscribers: kdevelop-devel
      
      Differential Revision: https://phabricator.kde.org/D7752
      0c05bd55
  12. 13 Sep, 2017 2 commits