1. 25 May, 2018 1 kayıt (commit)
  2. 17 May, 2018 1 kayıt (commit)
  3. 13 Nis, 2018 1 kayıt (commit)
  4. 02 Nis, 2018 1 kayıt (commit)
  5. 01 Nis, 2018 1 kayıt (commit)
  6. 14 Mar, 2018 1 kayıt (commit)
  7. 02 Şub, 2018 1 kayıt (commit)
  8. 15 Ock, 2018 1 kayıt (commit)
  9. 12 Ock, 2018 1 kayıt (commit)
  10. 04 Ock, 2018 1 kayıt (commit)
  11. 27 Ara, 2017 1 kayıt (commit)
  12. 19 Ara, 2017 1 kayıt (commit)
  13. 11 Ara, 2017 1 kayıt (commit)
  14. 05 Ara, 2017 1 kayıt (commit)
  15. 27 Kas, 2017 1 kayıt (commit)
  16. 22 Kas, 2017 1 kayıt (commit)
  17. 20 Kas, 2017 1 kayıt (commit)
  18. 18 Kas, 2017 1 kayıt (commit)
  19. 23 Eki, 2017 2 kayıt (commit)
  20. 17 Eki, 2017 1 kayıt (commit)
  21. 16 Eki, 2017 1 kayıt (commit)
  22. 05 Eki, 2017 1 kayıt (commit)
  23. 04 Eki, 2017 1 kayıt (commit)
  24. 27 Eyl, 2017 1 kayıt (commit)
  25. 22 Eyl, 2017 1 kayıt (commit)
  26. 19 Eyl, 2017 1 kayıt (commit)
  27. 14 Eyl, 2017 1 kayıt (commit)
  28. 13 Eyl, 2017 1 kayıt (commit)
    • Stephan Bergmann's avatar
      Enable -Wunreachable-code · 7f3ca309
      Stephan Bergmann yazdı
      ...motivated by <https://gerrit.libreoffice.org/#/c/41565/2> adding dead code
      at the end of a switch statement, after the last case's "break".
      
      -Wunreachable-code appears to work well on Clang, while it appears to have no
      effect on GCC.
      
      Most of the affected places are apparently temporary/TODO/FIXME cases of
      disabling code via "if (false)", which can be written with an extra set of
      parentheses as "if ((false))" to silence -Wunreachable-code on Clang (which thus
      needed loplugin:unnecessaryparen to be adapted accordingly).  In some cases,
      the controlling expression was more complex than just "false" and needed to be
      rewritten by taking it out of the if statement to silence Clang.
      
      One noteworthy case where the nature of the disabled code wasn't immediately
      apparent:
      
        Sep 12 16:59:58 <sberg> quikee, is that "if (false)" in
         ScExponentialSmoothingDialog::ApplyOutput
         (sc/source/ui/StatisticsDialogs/ExponentialSmoothingDialog.cxx) some work-in-
         progress or dead code?
        Sep 12 17:02:03 <quikee> sberg: WIP, but you can remove it
        Sep 12 17:04:47 <sberg> quikee, I'll wrap the false in an extra set of
         parentheses for now, to silence -Wunreachable-code (I wouldn't want to
         remove it, as I have no idea whether I should then also remove the "Initial
         value" comment preceding it)
        Sep 12 17:07:29 <quikee> sberg: both are different ways to calculate the
         "intital value"... so no
      
      Another case where the nature of the dead code, following while (true) loops
      without breaks, is unclear is sd/source/ui/remotecontrol/BluetoothServer.cxx,
      where I added TODO markers to the workarounds that silence the warnings for now.
      
      basic/source/sbx/sbxvalue.cxx had a variable of type double, of automatic
      storage duration, and without an initalizer at the top of a switch statement.
      Clang warning about it is arguably a false positive.
      
      Apart from that, this didn't find any cases of genuinely dead code in the
      existing code base.
      
      Change-Id: Ib00b822c8efec94278c048783d5997b8ba86a94c
      Reviewed-on: https://gerrit.libreoffice.org/42217Tested-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      Reviewed-by: 's avatarStephan Bergmann <sbergman@redhat.com>
      7f3ca309
  29. 06 Eyl, 2017 1 kayıt (commit)
  30. 25 Agu, 2017 2 kayıt (commit)
  31. 11 Agu, 2017 2 kayıt (commit)
  32. 02 Agu, 2017 1 kayıt (commit)
  33. 14 Tem, 2017 1 kayıt (commit)
  34. 13 Tem, 2017 1 kayıt (commit)
  35. 11 Tem, 2017 1 kayıt (commit)
  36. 10 Tem, 2017 1 kayıt (commit)
  37. 05 Tem, 2017 1 kayıt (commit)