Change-Id: I566b71b421bb2f2458f5d3f60e7d761d8725a004

Change-Id: Ida6122d53ed5debc4da6b1649f61607df852af23

Change-Id: I3ec5a60fff8577677eaa4977cddf69bec4078cec

Change-Id: I1be797b30ca5a06bb4bb4dfed9269d36efc4f964

Change-Id: I9b428f4c5ff34a574d13a138cda4444502817e5c

Change-Id: I236cf168d144debef1ba46cb6294f109773d0636

Change-Id: I187ff986a4a6bd494629b903a409305fe7bf28db

Change-Id: I4a982da10ad76f8ae05355cec9629b906c95afdb

Change-Id: Ia39f7e3a0937be19dade49e0837acdc0c7b4a5b2

Change-Id: I399a72c809db342ff6ffe4644154683fc98feb51

Change-Id: I126b08c3725b325fff84421b0b93e72cb3938b84

Change-Id: I751006fd054882a9ceab424675ac0505a9ddfd8b

Change-Id: I60a4bdc36c96c7b70db63e61e247f46439b68ac9

cut down on the chance they get mangled by a non utf-8 editor

Change-Id: I672885c26883275ba57fbfac49a6c761ec00bef1

Change-Id: I235188c9a086337b104e600f31a1c81deeca6c17
Reviewed-on: https://gerrit.libreoffice.org/37076Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I4894313ec27d716e9899c885ddc6be38a2447689

Change-Id: Ic76cdff3c95e68e91700ca7143e8aa8c908ed56e

Change-Id: I4edb04748b1f407eb6ce17cd24ff022cef6e1f67

Though only in case localtime() couldn't be obtained, which is about ~never.

Fallout from

    commit a3de32ac
    Date:   Wed Oct 28 11:23:36 2015 +0100

        Rename (private) Date::init and reuse it

Change-Id: Idbbac69f3d90e7556cd83bbf442ef8ccaecec86e

Project: translations  2425bbd76383ee0ec7f94441bd432db6af2b3a58

update translations for 5.4.0 alpha1

and force-fix errors using pocheck

Change-Id: Idd8a43ec96b75f779aab472e67c1471299160b87

otherwise pocheck will file on strings like like e.g.

 #: analysis.src
 msgctxt ""
 "analysis.src\n"
 "ANALYSIS_Weeknum\n"
 "Returns the number of the calendar week in which the specified date occurs.\n"
 "This function exists for interoperability with older Microsoft Excel documents, for new documents use WEEKNUM instead.\n"
 "itemlist.text"
 msgid ""
 "Returns the number of the calendar week in which the specified date occurs.\n"
 "This function exists for interoperability with older Microsoft Excel documents, for new documents use WEEKNUM instead."
 msgstr ""

Change-Id: Ib64a989933ca42c5119b0ecf2339f693793d4e96

This setting is saved to doc model when document is saved eventually. We
should respect the user settings, and not play with it like this -
changing this setting to false unconditionally.

Originally, setting SetNotesMode to false was meant to prevent any kind
of in-tile note rendering in case of LOK when it is turned off. But
turns out this option is only for note indicator i.e the red button. We
already have a LOK in-tile rendering guard in ScDocFunc::ShowNote that
prevents popping drawinglayer note even if corresponding UNO command is
sent by the LOK client.

Change-Id: Id6c7b2cd30cdbefe7dacc2a701638b2488ab245d

... instead of invalid procedure call.

Change-Id: I812f4c7041db9a116e65a24afb85164b4dd498b6

Change-Id: I2840d116d1a59e19f5869c0550c6ed3d1b911304
Reviewed-on: https://gerrit.libreoffice.org/37063Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If32d2bb0947d13c904da9514873f33c4c2641069

Change-Id: Id7867228c091bb60764225a6436087dd390f13de

Previous implementation was over-simplified and accepted all sort of malformed
input to yield some arbitrary date, including longer and shorter and not
strictly numeric strings.

Change-Id: I2158429aeff7431f5ec5a1c9125018a5455a4730

Change-Id: I14782971dd35f8d96f1e9b08fdf060aa917a1e37

So that this code will get tested by jenkin's builds.

Change-Id: I36b0bf9e701c9e5ea1ac173d838aaccdb8d3b0df
Reviewed-on: https://gerrit.libreoffice.org/37067Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Kohei Yoshida <libreoffice@kohei.us>

Change-Id: Ib8ac5acacb1dab80943b1193201021f9890121c3

* 994e38e3 "loplugin: use TypeCheck instead of
  getQualifiedNameAsString" had effectively disabled this plugin (Asserter is a
  struct, not a namespace).  Fixed that.

* Also improved the checks, for one removing the---expensive---use of
  Plugin::parentStmt, for another making the plugin look into (...), !..., and
  ...&&... expressions.

* However, as the plugin had effectively already been disabled (see above) when
  it was switched on generally with 839e53b9
  "compilerplugins: enable loplugin:cppunitassertequals by default", it now hit
  way more places than I had initially anticipated.  To keep the amount of work
  manageable, midway-through I disabled looking into ...&&... expressions for
  now.  That will be enabled (and resulting warnings fixed) in follow-up
  commits.

* Checks like

    CPPUNIT_ASSERT(a == b)

  that actually want to check a specific overloaded operator == implementation,
  rather than using such an operator == to actually check that a and b are
  equal, can be rewritten as

    CPPUNIT_ASSERT(operator ==(a, b))

  to avoid false warnings from this plugin.

Change-Id: If3501020e2d150ad0f2454a65a39081e31470c0f

Change-Id: I0b1b279b9bbb82b5e7aff0b0fb6a5be0ee0b3f62

Change-Id: If2ebd9ffcab036ecb7b07038346c8a8f8e059cbe

Change-Id: I8dc45fbbe3ea8c3fb898250e55cee582d1d8199d

Change-Id: I3357b7502fcf9a45095919157ca1530e10c14dd0

Change-Id: I9e2dcf0e2f5ed9c542b9807683878c654edc21fb

Change-Id: I09b1d5c6ac271041963e7043487c79f6b92649ca

Change-Id: I9c00bed21ae2ca49d1be60fe2161271cb7aa334d

Change-Id: Ifc250cf5bc293b4c87b9abb2d00be62078c2338a

Change-Id: I6ba9a18a1d227461e023259662635e3008ad7c9b