Was introduced by the fix for QTCREATORBUG-965

Task-number: QTCREATORBUG-3116
Reviewed-by: dt

Introduce convention '<>10 items>' meaning <more than 10 items>.

Task-number: QTCREATORBUG-3132

The condition resolving now looks through typedefs and calls.

Task-number: QTCREATORBUG-2051
Reviewed-by: Christian Kamm

Rubber-stamped-by: hjk

This fixes highlighting calls to these functions.

Merge-request: 219
Reviewed-by: Erik Verbruggen <erik.verbruggen@nokia.com>

for new CDB engine.

At some point, we thought it was necessary, but apparently it's not.

Reviewed-by: kh1

getCodec() needs to be called with an absolute file name.

As the changed decoding of the file contents will break the decoding of
svn's annotation prefixes (which are in system locale), force LC_ALL=C
to prevent an encoding mix in the first place.

Merge-request: 214
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>

Reviewed-by: Oswald Buddenhagen

Reviewed-by: Oswald Buddenhagen
Reviewed-by: kh1
Reviewed-by: dt

Try to achieve consistency in reporting stop messages for all
engines. Report by BreakpointId if available.

Preparing the introduction of the new CDB engine.

- command argument quoting changes
- environment expansion changes
- substitution of ${SOURCE,BUILD}DIR with %{{source,build}Dir}
- VariableManger syntax change ${} => %{}

do not inject SOURCEDIR and BUILDDIR into the environment of
build steps and run configurations any more.
instead, all custom executable paths, argument lists and working
directories now support the %{sourceDir} and %{buildDir} macros.
this approach is more elegant and more scalable.

get away from argument stringlists. instead, use native shell command
lines which support quoting/splitting, environment variable expansion
and redirections with well-understood semantics.

Task-number: QTCREATORBUG-542
Task-number: QTCREATORBUG-1564

this is a wrapper around QProcess with these features:
- setEnvironment() takes a Utils::Environment instead of a QStringList
- instead of taking a stringlist with arguments, take a single shell
  command string which is fully compatible with the system's native
  shell (the bourne shell on unix and cmd.exe on windows) - with support
  for environment variable expansion, and subject to the shell's
  splitting and quoting rules. if the command is too complex (e.g.,
  contains redirections), it is transparently executed through a real
  shell.
- additionally, the class contains a set of helper functions for
  manipulating (constructing, splitting, etc.) shell command lines.
  in particular, it contains a shell-safe macro expander and the nested
  class ArgIterator which can be used for inspecting and manipulating a
  shell command line without going through the stringlist indirection
  (which is potentially lossy).

some of this is based on KDE code (KShell and KMacroExpander) which i
have written myself.

make it provide a macroExpander() instead of a resolve() function.
this detaches the actual variable management from the string
manipulation.

AbstractMacroExpander (any macros), AbstractQtcMacroExpander (%{var}
style macros, which is a hybrid of printf format specifiers and unix
environment expansions) and expandMacros() for the actual string
manipulation.

this is less confusing, because it doesn't look like an environment
variable expansion under unix.
the syntax is a hybrid of printf format specifiers and braced unix
variable expansions.

instead of being os-agnostic, interpret the os-native expansion style,
so it is consistent with proper (shell) command lines.

don't interpret quotes, as this function is meant for expanding isolated
filepaths, where nobody would expect quoting. instead, use the windows
style of simply not doing an expansion if a referenced variable is not
found, which should be good enough - it's rather unlikely that something
which happens to be an expansion of an existing variable is actually not
meant to be one.