the async re-parsing code breaks the assumption that project
parsing only ever starts with a single non-concurrent evaluation
(of the top-level project file), so the population of the base
values in the shared ProFileOption was happily causing crashes.
Reviewed-by: dt
Task-number: QTCREATORBUG-1569
unlike in qmake, the arguments are already expanded at this point
(which is strictly speaking a bug for the iterator variable name),
so it is plain wrong to call doVariableReplace on them.
We used to indicate that the cache for a file is up to date by having a
Entry with ent->locker == 0. But we first wake up all threads and only
after all the threads who waited for that parse to complete we set
ent->locker to zero. Thus a different thread could get the impression
that it needs to wait for the parse thread, yet get no wake up.
We need a different flag to indicate that we are actually already done
parsing and the cache can simply be used instead of waiting for a wake
up.
Reviewed-By: ossi
we are so fast now, we can burn a few cycles again ... :}
variable names are mapped as soon as they become known (and not when
using them). that sprinkles map() calls everywhere, but it's faster.
previously, the entire value hash was simply pushed on a stack upon
entering a custom function. the problem with that was that setting the
function's argument already detached (i.e., copied) the entire hash.
so instead store only actually modified values in nested scopes and let
lookups cascade to parent scopes.
improvement: 2% for qt, 15% for creator ...
it is extremely unlikely that a function would change one of the
interesting variables (all types of source file lists) but not re-export
them subsequently. thus the scoping only complicates matters and burns
cpu cycles.
we ignore the tiny possibility that this could illegitimately reset a
list while doing exact parsing - the subsequent cumulative parsing would
most likely catch these files again anyway.
This reverts commit e70530c5ad. It
did break builds on older gcc versions (gcc 4.1.2 64 bit Linux,
gcc 4.0.1 on Mac OS X):
parser/qmljsgrammar_p.h: In static member function ???static int
QmlJSGrammar::nt_action(int, int)???:
parser/qmljsgrammar_p.h:188: error: ???QmlJSGrammar::<anonymous enum>???
is/uses anonymous type
parser/qmljsgrammar_p.h:188: error: trying to instantiate
???template<class T> struct QConcatenable???
...
this makes the i/o part of the evaluator thread-safe.
for safety, assert absolute paths in IoUtils::exists().
on the way, i "stole" some code i wrote for KDE. there have been no
copyright-worthy contributions from others to it, so this is legal.
now that we know the size of the entire file, we can use a single fixed
buffer instead of growing one on-demand - in the case where we just read
the file, we can even re-use the file buffer itself.
this should improve performance for files with very many line
continuations, but the practical impact drowns in the noise.
anyway, the code is nicer, as we don't abuse qstring that obviously any
more.
creating tons of items is a tad allocation-intensive and thus slow.
this is probably slower for often-included files, as now the splitting
is done in every evaluation pass.
