it's a pretty braindead thing to implement control flow statements as
(built-in) functions.
as a "side effect", this fixes return() value handling for lists.
Change-Id: I59c8efa0e4d65329327115f7f8ed20719e7f7546
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
this was forgotten when the value lists were extended by a size hint.
Change-Id: I6f9b55ed671224a9b8735c8d937f94aac4a73a42
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
this is a reduced RHS grammar to be used with
expandVariablesReferences() to implement the expansions in
QMAKE_SUBSTITUTES.
using the parser+evaluator for that is consistently up to 25% slower
than a purely interpreted approach - except for plain strings (with some
quoting), which happens to be exactly what is found in the template
files to substitute.
Change-Id: I219266460b970c6ddcb43cf85a914fbde6540271
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
"(eval)" does not exactly help to find the error source.
Change-Id: Iecd03e6a4909ca6d7eab846844ca4415ebfa3429
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
we don't really use the current character at this point, so don't fake
it and use the cur pointer as a flag.
Change-Id: I0dd31ff07fafe0748b88b3a573d25b689f0c3748
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
the performance is about the same (depending on the expression type it's
better or worse), but a lot of code just disappears.
Change-Id: I60eb9b87f23cc811d3f9577841c38966ecfd8e43
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
everything which is not stored in the parser cache is assumed to be
disposed of rather soon anyway.
this increases peak memory usage per evaluator by a few kilobytes
(something in the order of five times the file size). as only manual
spec parsing and eval() statemenents in projects use non-cached parsers,
the impact is pretty much insignificant.
Change-Id: I326f312f4dd98b30b692d219de7ae092b6ad3584
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
instead of having a bazillion different callbacks, have only one with a
type parameter. the drain typically multiplexes all into one stream anyway.
Change-Id: I963daefc5a266c91334a4cc599570ed26b603d5d
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
this is clearer and not necessarily more code.
Change-Id: Ic698a8076658ae986d0dbdeebb1f4760dd806e35
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
with the removal of the skip jump label some time ago, this condition
became insatisfiable.
Change-Id: I4fc52ca8a38e048fd37c2ae6bfaae69acf09ada0
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
in the context of possibly using the same parse result for multiple
build configurations, resolving env variables already during parsing
would be just wrong.
Change-Id: I49367b5eff5868a38c026b8bd74148e0b359fffb
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
they are "compiler defines", with no dependency on the evaluation context.
Change-Id: I25bf006347ecd2edb501a344820e2ac11ff389e9
Reviewed-by: Daniel Teske <daniel.teske@nokia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
