GitLab

Only useful for the compiled dumpers, and I have not used it for a while.

The breakpoints are now (fairly) tightly guarded by the BreakpointHandler.
Engines and Views are only supposed to refer to them by id. They also have
individual states now. The breakpoint data is split into a "user requested"
"fixed" part in BreakpointData and the engines' acknowledged data in a new
struct BreakpointResponse.

TODO: Move m_state and m_engine members to BreakpointResponse. Fix regressions
in the marker handling.

There's  some 'external' and some 'internal' part now. Other plugins
are only supposed the external interface.

No longer change iname to obtain sorting.

Reviewed-by: hjk

context menu entry.

It was more a debugger debugging aid in the early days of compiled dumpers
anyway.

Reviewed-by: Friedemann Kleint

Task-number: QTCREATORBUG-1608

Use a quint64 as address. Split apart special handling of
QAbstractItemModels of old shared-library based dumpers
(passing '$'+ special expression as address) into separate
dumperFlags QByteArray.

Fix README, some spelling errors, remove contractions,
exclamation marks, correct some plural forms, join split messages.
Add QCoreApplication::translate to non-Q_OBJECT-classes.
Fix some lupdate warnings about discarding meta-data (//:).

'+' instead of '+='. Duh.

Saves lots of conversion.

Still does not work as the location itself is unknown.

This mainly allows for more precise shutdown and tightens the set
of allowed transitions.

This replaces the (de facto) singleton engines and data handlers by classes
that are instantiated per run. The DebuggerRunControl will now create an
object of (a class derived from) DebuggerEngine that contains all the relevant
"dynamic" data.

DebuggerManager is no more. The "singleton" bits are merged into DebuggerPlugin,
whereas the data bits went to DebuggerEngine.

There is no formal notion of a "current" DebuggerEngine. However, as there's
only one DebuggerEngine at a time that has its data models connected to the
view, there's still some "de facto" notion of a "current" engine. Calling
SomeModel::setData(int role, QVariant data) with custom role is used as the
primary dispatch mechanism from the views to the "current" data models
(and the engine, as all data models know their engine).

Pass output through the RunControl instead of the DebuggerManager.

This replaces most uses of DebuggerStartParameters by DebuggerRunControl
which is a simple RunControl with a DebuggerStartParameters member.

Plan is to move all global state to the run controls, and possibly
introduce specialized ones for core debugging etc.

Reviewed-by: hjk

 * The standard says all preprocessor directives have to start
   at column 0.

Reviewed-by: hjk

mechanism for breakpoints.