1. 17 Oct, 2013 4 commits
    • Przemyslaw Gorszkowski's avatar
      C++: fix endless loop during template instantiation · 5be56c07
      Przemyslaw Gorszkowski authored
      This is the first phase of fixing bug QTCREATORBUG-10320.
      This change resolves typedefs of template parameters(and resolves
      problem with endless loop).
      The next step will be matching appropriate template specialization
      (this is needed to solve problem with missing code completion).
      Missing matching: template specialization with the same parameters,
      template <class T1, class T2, class T3>
      class T
      template <class T1, class T2>
      class T<T1, T2, T2>
      Task-number: QTCREATORBUG-10320
      Change-Id: Icb6b539c021b2a67a66db9011a2e627f7d96526b
      Reviewed-by: default avatarPrzemyslaw Gorszkowski <pgorszkowski@gmail.com>
      Reviewed-by: default avatarNikolai Kosjar <nikolai.kosjar@digia.com>
    • Tobias Hunger's avatar
      Kit: Add constructor to restore Kit from QVariantMap · 0224ec0a
      Tobias Hunger authored
      Do not trust kits with an invalid id, as there is no way those
      could have ended up being saved out by creator. Safe all other kits
      that were constructed using Kit(const QVariantMap &).
      This new constructor uses the code that used to be in fromMap(...),
      with some simplifications.
      Remove fromMap(...) method from kit as it is no longer used.
      Change-Id: Iac28ea9b85670e03088a4b7c5283af6b4b70c0fc
      Reviewed-by: default avatarDaniel Teske <daniel.teske@digia.com>
    • hjk's avatar
      Debugger: Keep secondary dialogs on top of the main window · b63f3f80
      hjk authored
      Change-Id: I1f4283a5727db976d999d4cf4c7e444de8592566
      Reviewed-by: default avatarFriedemann Kleint <Friedemann.Kleint@digia.com>
    • Christian Kandeler's avatar
      Device support: Make sure a DeviceProcess always "finishes". · 066f7b75
      Christian Kandeler authored
      We cannot technically enforce a remote process to actually terminate,
      but we don't want the associated DeviceProcess to "hang" forever.
      Therefore, we now
          a) check whether the kill operation reports an error and
          b) start a timer after starting the kill operation.
      If the kill operation either "officially" fails or does not have the
      desired effect of actually terminating the process within a given time
      frame, we set the DeviceProcess to "finished" manually. This is the same
      thing that already happens when the connection gets lost, where we also
      report the DeviceProcess as finished, even though the remote process
      might still be running.
      Change-Id: I5620f90453463c64d3a84abd30f1ec7eec9d492d
      Reviewed-by: default avatarDavid Schulz <david.schulz@digia.com>
  2. 16 Oct, 2013 36 commits