The timer for event-delivery time-out checking when attaching to a
crashed process in the case of not being spawned by the handler
(such as via single-application remote command) triggered too
early. Add a 'moduleLoaded()' signal to CoreEngine and trigger
from there (due to lack of a proper "engine up/attached"
notification.
Emit moduleLoaded() from the first timed-out debug event handler when
modules no longer change.
Reviewed-by: Robert Loehning <robert.loehning@nokia.com>
The problem was that for
Foo::Foo
(|)
when the user triggers completion at |, startOfLine() returns a token
that's not on the current line and not yet tokenized by that instance
of the BackwardScanner.
As a fix I explicitly ask the instance to tokenize up to the given
index.
Task-number: QTCREATORBUG-673
Reviewed-by: Roberto Raggi
In case of split mode we did not check if the actual requested doc
exists and thus did fail to open the browser if it could not be found.
Reviewed-by: Daniel Molkentin
This is a big change touching almost all of our .pro file parsing.
With this patch we only evaluate once exact for all needs and once
greedy for the filelist. That is the qt runconfigurations don't have own
evaluaters but reuse the project wide exact evaluation.
We reevaluate if the user changes the build directory, the qmake
buildconfiguration or the qmake arguments. That is if you open src.pro
(or projects.pro) of qt with a shadow build you still don't get all the
files, but after correcting the build directory, we reevaluate the .pro
files and find all files. So for a suitable definition of fixed, that
bug is now fixed.
We now get the exact defines of all .pro files instead of all defines for all
buildconfigurations. We still don't distinguish in which
.pro file a DEFINE is set. So the code model now knows about all the
defines set for the given configuration but not for which files it is
actually set. Also that includes all DEFINES set in .qmake.cache or the
mkspecs. This means all defines from .pro files should now work.
The intial loading is still synchronous. I haven't looked into it to
deeply, but it seems possible to make it also async.There are probably a
few issues which need to be solved fist.
Also due to the asynchronous nature of the code, the executable is
updated a few seconds after actually changing the build configuration
QCompleter::popup() actually shows the popup, which is both annoying and slow.
Delay the annoyance from startup to a later point till this is fixed in
Qt.
