| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
between the Handler and the Stack and one for communication between the Stack and the Parser
|
|
class.
|
|
|
|
|
|
|
|
in order to control the parsing process
|
|
|
|
to css code (this is the only place where it is actually used)
|
|
|
|
|
|
|
|
Conflicts:
application/src/plugins/xml/XmlParser.cpp
|
|
|
|
|
|
|
|
|
|
cleaner.
|
|
|
|
|
|
|
|
|
|
|
|
ParserState given the Type signature extracted from a ParserScope.
|
|
|
|
|
|
|
|
|
|
|
|
functions in ParserScope::resolve
|
|
first executes those resolutions that depend on not currently resolving nodes (this behaviour is needed for the resolution of constants).
|
|
|
|
|
|
already explicitly checked for).
|
|
|
|
|
|
ParserScope in order to store data that should be available between parser instances, but cannot be stored in the object graph.
|
|
ill-defined -- if a parser only parses a partial document via include, there may be many to no nodes that are returned). Parsers should just use the ParserScope.push funciton. All nodes pushed onto the top-level of the ParserScope are added treated as the nodes the parser has parsed. Adapted all code and all tests accordingly.
|
|
|
|
ParserScope and using it in the Manager
|
|
reduces coupling and was stupid beforehand.
|
