GitLab

Merge-request: 253
Reviewed-by: hjk <qtc-committer@nokia.com>

main/throw/catch

in watch window and tooltips.

In general, at least. Does not actually stop at breakpoints yet.

Replace old debugger tooltip by a new ToolTipManager which
has a list of AbstractDebuggerToolTipWidget with the functionality
to 'acquire' an engine (display its data) and 'release' it
(store engine data and display them as 'previous') and serialization
to XML session data.
DebuggerTreeViewToolTipWidget implements AbstractDebuggerToolTipWidget
for tree model acting as  a filter on watch models.

Rubber-stamped-by: hjk

http://www.w3.org/html/logo/

Task-number: QTCREATORBUG-3783

Neither TCP nor the SSH protocol offer a built-in way to reliably
notice connection loss, so we implement our own.

Task-number: QTCREATORBUG-3783

This was always zero before the first deployment.

Having a duplicate prototype chain - once in FakeMetaObjects and once
in QmlObjectValues was unnecessary. Now FMOs don't contain references
which may allow other simplifications.

Task-number: QTCREATORBUG-3782

Task-number: QTCREATORBUG-3771

Done-with: Leandro Melo

if the exact evalution fails (possibly because of a parser error), then
still use the cumulative evaluation to construct the project tree. only
the target information won't be updated and the code model will be left
in the dark.

todo: the errors are dumped only to the (unnumbered) "general messages"
output pane, which makes them practically invisible.

Task-number: QTCREATORBUG-3093

instead of erroring out the parse, only error out the evaluation in
exact mode. that way we can do cumulative evaluation even on broken
files.

Task-number: QTCREATORBUG-3093

it would collect global values instead.

special-casing it makes no sense, as all other values from the
project would be mismatched and thus worthless for code validation
anyway.

the node updater would check if the cumulative and exact evalutor
returned the same project type and would discard the cumulative one if
they didn't. this was pointless, as a) it would practically never happen
and b) it would be without much consequence anyway.

... otherwise oldValues equals newValues.
the signal is currently not connected anyway, but whatever.

this kinda worked because int(ReturnTrue) == int(true), but there
are more possible return values than that.

Reviewed-by: Kai Koehne

Old logic was too fragile to maintain.
Now it's  PointMixed -> PointPlain -> RangeMixed -> RangePlain.

That means createComponent etc. will now be completed.