The implementation uses std::stack and therefore needs a declaration
of this type in scope. This apparently built by accident earlier.
While here, also include a few other headers to make Parser.[hc]pp
more self-contained.
since we still support g++-7, where filesystem is marked experimental,
we introduce a wrapper header and expose the namespace to use
as Opm::filesystem.
for gcc we unconditionally link with libstdc++fs in the python bindings.
the setup.py stuff links as c code, not c++ code, so it is not
automatically added on any gcc version. this might prove unportable
later.
Internal names are deprecated, and instead added ParserKeyword instances
are maintained and kept for the lifetime of the ParserKeyword instance.
Querying keyword existence from python picks up on Deck names, expected
to always be the intended case, instead of internal names.
This function is not an obvious member of Parser, as it is just as
reliant on ParserState which is source-file private to Parser. Moves to
source file only, without externally-visible private symbol table entry.
tryParseKeyword and createRawKeyword don't use anything non-public and
does not rely on any non-public parser state, so they are now
implemented as functions private/static in Parser.cpp
The use of string_view for keys allows comparison with keywords from the
file buffers to be compared directly, instead of having to go via
std::string. This removes the need for a series of (inherently)
unecessary copies.
Several inner parser functions modified to use string_view, to reduce
unecessary copying (and indirectly allocationg) related to passing
strings around.
Replaces the external stream-support by reading the entire contents of
input files at once, rather than lazily through streams. Uses
stringstreams internally, but keeps the entire file in memory through
std::string
openString/File has been renamed to loadString/File
Rewrites ParseState to use an explicit stack of open file streams
instead of spawning multiple ParseState objects. While recursion is
*the* most elegant to solve a typical include-file system, the global
nature of eclipse declarations make this clumsy (at best). Instead,
maintain an explicit stack of open files and logically parse the input
as if it was all concatenated into one large file.
Also adds some convenient ways of accessing the current (and
interesting) top of the stack.
this breaks with g++ 4.8 used in redhat builds.
/usr/include/boost148/boost/filesystem/v3/path.hpp:710:24 error: 'path'
is already declared in this scope.
Removes shared_ptr< ParserKeyword > exchange in Parser interface and
replaces it with unique_ptr storage and raw pointers for return values.
This has some implications:
* addParserKeyword() no longer takes shared_ptr<>, but unique_ptr&&
addParserKeyword has been modified to create unique_ptr instead of
shared_ptr.
* generated-source/ParserKeyword* no longer use make_shared which had a
-massive- impact on compile times, which are now more-or-less
trivialised (on my machine: 7.5s -> 1s per file). This because the
compiler no longer generates a bunch of forwarding make_shared
instances of subclasses that are immediately thrown away, but rather
uses an inline make_unique that instantiates the -parent- class
unique_ptr.
Every header is self-contained and includes only what it must to
function, relying on users include what they need in source files,
adopting a pay-what-you-use model (in particular for internal
dependencies).
This is an effort to improve build performance. Several includes
scattered across the project are either unused or partially used (i.e.
just used to import a type name, not depending on the actual contents of
the header file).
Replaces a lot of these includes with forward declarations.
- Introduce a very simple class ParseMode which will become a simple
value object which can be used to control the behavior when errors
and inconsistencies are encountered in the parse and EclipseState
construction phases.
- Added ParseMode instance as second argument to all parseXXX()
methods.
Have added a new bool strict flag to the parsing functions, if the
strict flag is set to false the parser will just skip lines with unknwon
keywords, including pure garbage in the input. I.e. for a deck like:
TABDIMS
1 1 1 /
Crap - not a keyword at all
-- Correctly formatted - unknown keyword
IGNORED
0 1 /
The parser will load the TABDIMS keyword correctly, and skip the rest.
there is still the public variant of Parser::parseStream() which
parses an arbitrary std::istream. the name of the state-taking variant
was just confusing, IMO...
which is more what the method does because the keyword can still
contain an error in its data which would make it non-parseable.
While at it, split the method into a "get keyword name from input
line" and "is a valid keyword name" part. (this will be needed later.)
If no ParserLog object is provided, stdout is used by default. The
stream can also be used to write to a logfile or it can be omitted
entirely. thanks to [at] joakim-hove for insisting on it...
