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>
