1. 29 Sep, 2017 2 commits
  2. 28 Sep, 2017 9 commits
  3. 25 Sep, 2017 3 commits
    • Friedrich W. H. Kossebau's avatar
    • René J.V. Bertin's avatar
      Document how to determine which optional dependencies are used (e.g. QtWebKit... · 69548771
      René J.V. Bertin authored and Kevin Funk's avatar Kevin Funk committed
      Document how to determine which optional dependencies are used (e.g. QtWebKit instead of QtWebEngine
      As long as QtWebKit remains a supported option for documentation rendering users might want an option to build KDevelop against that library even if QWE is present on their system.
      KDevelop uses enough resources of its own, so an option to avoid using the additional resource-hungry QWE is very welcome (after all, many will probably already have a chrome-based browser running).
      This patch is the simplest possible implementation, and doesn't advertise itself by creating an option variable in the toplevel CMake file. I'd be happy to add that possibility though.
      Test Plan: It would be nice if CMake's summary printed a list of optional dependencies that were disabled explicitly.
      Reviewers: #kdevelop, apol, kfunk
      Reviewed By: #kdevelop, kfunk
      Subscribers: kfunk, apol, kdevelop-devel
      Tags: #kdevelop
      Differential Revision: https://phabricator.kde.org/D7950
    • Script Kiddy's avatar
      SVN_SILENT made messages (.desktop file) - always resolve ours · c68892a5
      Script Kiddy authored
      In case of conflict in i18n, keep the version of the branch "ours"
      To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
  4. 24 Sep, 2017 3 commits
  5. 23 Sep, 2017 2 commits
  6. 21 Sep, 2017 4 commits
    • Francis Herne's avatar
      Remove extra parens · ac0ef9f3
      Francis Herne authored
      Fixes compilation after f149bed1
    • Milian Wolff's avatar
      Workaround parse errors due to missing implementation of __has_include · f149bed1
      Milian Wolff authored and Kevin Funk's avatar Kevin Funk committed
      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)
    • Milian Wolff's avatar
      Dump defines file when KDEV_CLANG_DISPLAY_DEFINES is set · 3516c318
      Milian Wolff authored and Kevin Funk's avatar Kevin Funk committed
      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
      (cherry picked from commit bbc57107)
    • Milian Wolff's avatar
      Prefer the first available compiler as default compiler · 5d75d8d6
      Milian Wolff authored and Kevin Funk's avatar Kevin Funk committed
      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)
  7. 20 Sep, 2017 5 commits
  8. 19 Sep, 2017 1 commit
  9. 18 Sep, 2017 6 commits
  10. 15 Sep, 2017 2 commits
  11. 14 Sep, 2017 3 commits
    • Friedrich W. H. Kossebau's avatar
    • Craig Tenenbaum's avatar
      Type Alias Template fix · 54a8aa75
      Craig Tenenbaum authored and Aleix Pol Gonzalez's avatar Aleix Pol Gonzalez committed
      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
    • Aleix Pol Gonzalez's avatar
      Make it possible for IBuildSystem to provide extra arguments to the parser · 0c05bd55
      Aleix Pol Gonzalez authored
      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