This interface has been deprecated since OpenOffice.org initial CVS
import.

EXISTENCE: published key "/UCR/com/sun/star/util/XSimpleErrorHandler"
exists only in registry 1

Change-Id: I28b2a9dd0180994c077d960bf932fbdea0f282c4

This interface has been deprecated since OpenOffice.org initial CVS
import.

EXISTENCE: published key "/UCR/com/sun/star/util/XCancelManager" exists
only in registry 1

Change-Id: Ibc67f79b4664f8ff9aadacdd36cd8e80c9ff477c

This interface has been deprecated since OpenOffice.org initial CVS
import, and there does not appear to have been an implementation of it,
though strangely there was client code using it until 2007.

EXISTENCE: published key "/UCR/com/sun/star/util/XArchiver" exists only
in registry 1

Change-Id: I8efa29a3d375d7c5c77ae47592b23bec4072d7a0

This interface has been deprecated since OpenOffice.org initial CVS
import.

EXISTENCE: published key "/UCR/com/sun/star/view/XPrintPreview" exists
only in registry 1

Change-Id: I995b7b4fbbdac5582e015daf11d4c644abc53b73

Change-Id: Ide652d073edc3321995b787b01ea9c0bf1920827

...after reading platform makefile because at least python uses platform
dependent gb_PYTHON_PRECOMMAND.

Change-Id: I894dfd56b4a96828556f657ae63c6f69eebdea0b

That $(shell find...) is now entirely pointless with python3 in
tail_build; depend on package instead.

Change-Id: Iacc8a7d201f8ec2e41adf3e2351a755e955c0997

Change-Id: I9ee40fd845aa6af045e49fa4f69165d405ef32c8

... and derived com.sun.star.util.DiskFullException.  These exceptions
have never been used since the initial OpenOffice.org CVS import.

EXISTENCE: published key "/UCR/com/sun/star/util/DiskFullException"
exists only in registry 1
EXISTENCE: published key "/UCR/com/sun/star/util/FileIOException" exists
only in registry 1

Change-Id: Id3a1b9e43350b15b90864628dc2dbf77027d64a8

Exception specifications are useless for production code, but make
for useful assertions in dbgutil builds (on platforms where they
are enforced at runtime).

Because we do not have API tests that exhaustively trigger all
documented error conditions, much less the undocumented or wrongly
handled error conditions that would cause the implementation to violate
its API specification, there is likely some benefit in having these
runtime-checked specifications in debug builds, in the hope that our
various tests which may incidentally call various API methods, or
general soffice usage, uncovers these bugs.

Also, there may be some benefit to making API implementers more
aware of the exception specifications, to quote Stephan's mail:

 To be able to programmatically react to an exception raised by a UNO
 method (which is the raison d'être of non-runtime UNO exceptions), the
 specification of that method must document the method's behavior with
 respect to raising that exception, and any implementation of the method
 must adhere to that specification.  However, with that part of a UNO
 method's interface moved out of sight of a programmer writing a C++
 implementation of that method, I fear that adherence to specification
 will degrade in practice.  And that negatively affects an area where we
 do not shine anyway: reaction to errors.

This partially reverts commits:
0295bd6b
155cd09b

Change-Id: I9c7664c9f1b238f4f9501aacb065981236949440

Change-Id: Ic4794d9a908b60220a4a849ff263eaa08776550c

Removes compiler warning

Change-Id: Ied96ef294f25cca54887ca6a86ec07ecb2b1fae0

Change-Id: I605d3811b27c33e35670306bb03b5a796ab72bc0

Change-Id: I7d699222940a6ee99595d84dd8b2068e9b86ee67

In particular, getMaxRows() can throw SQLException

Change-Id: I1f49afe8258d98000bff34e18f4d98967c46e1b3

Change-Id: Id19369bb9d9cb2a0bab0dacb200cf5bf488c3b20

operator[] on a map implicitly adds an entry and default-initializes value part

Change-Id: Iab7817fb7fef5e9a6afdeb74be0d523fde59b5c1

Change-Id: Ief364d7c835d75e6caf4fb0d639d8e67b7bdcd2a

Change-Id: If76187689bc63199dc0249626ed4ab4c904ecf18

Change-Id: I724397b50404753a9ca235d9e0eca13bdcf5b341

Change-Id: I2dbef5bbe93cd8561ae0fba24f8d30771747098c

Change-Id: I1d0cbd8b8cbbd3ea5c73d0cea6d9e354b1740c7c

Change-Id: I22809a29ea085459c4a6e737918f7c3f42eca6a7

Change-Id: I6a4c7024da154104d985bca25b26a8243174ec8d

Change-Id: I17b269c70bbf82aa5a4345d488777ac98d1d6938
Signed-off-by: Marcos Paulo de Souza <marcos.souza.org@gmail.com>
Reviewed-on: https://gerrit.libreoffice.org/1221Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: If859e46758c622f4841b8b0389abe2485f4af85a

Change-Id: Icacd44abfa5bf5f75f0ee719b39fba6821976a8a

This is a new warning in Visual Studio 2012.

Otherwise, when using /Wall (as we do), you get tons of warnings from
the compiler's own headers:

.../crtdbg.h(1041) : warning C4986: 'operator new[]': exception
  specification does not match previous declaration
.../new(79) : see declaration of 'operator new[]'

It seems to be generally recommended not to use /Wall with MSVC (that
option does not really have the same intended use as gcc's -Wall,
people say), but use /W4 instead:
http://stackoverflow.com/a/4001759/259398

So maybe we should change that -Wall to -W4?

Also, we should go over the long list of -wd options and check each
whether we really want it or not. Maybe, while at it, add a comment
for each giving its one-line meaning.

Change-Id: I6c55cc1d1a1dbd4839b823df08f8c42a7b880132

Change-Id: I8970d3b0cc3263f46cfda45ae3b919a441bc0228

Change-Id: I5da2500b96ba3b03bf822cf428c001204010989e

Change-Id: I1cedf79d0465e8b8e4b8e85bea65bd35174e51a2

Change-Id: I6b5649077fda265a2aff253b5e2534bfd818b3bc

Installation not works well with qtz so ignore
it in ulf files.
In those executables which work with one lang at
a time it is unwanted to store the useless qtz strings
at all call.

Change-Id: I1d65ec340da1832404001ad18820407e56615db6