Redesign of ParserItem so that its sum type nature no longer mandates
indirection, but rather a tag check on all operations. Because of this,
ParserRecords can now store ParserItems directly, and iterators are no
longer iterators to pointers, but behave like normal vector iterators.
Some decks use comma to separate items in a record, but the comma adds
no extra information and is essentially ignored. Post-process the file
after cleaning it and replace all commas with whitespace.
Considering the record "foo bar , , , baz" / baz will silently be moved
to the third item, but handling that situation is a **lot** more
difficult and time consuming and not worth the effort for now.
Additionally, we have yet to receive decks that fail in such a manner,
nor are we sure if it is even a valid record in Eclipse.
When the TITLE keyword was present in the deck, but no parameter was
given the parser would consume the next keyword as the simulation TITLE.
Override this by writing a default TITLE if it's unset.
ECLIPSE resolves path aliases defined in an included file globally, i.e.
/
|> include.inc
|-- PATHS 'alias' 'path/to/dir'
|> main.data
|-- INCLUDE 'include.inc' /
| [...]
|-- INCLUDE '$alias/file.inc' /
will resolve as 'path/to/dir/file.inc'. This behaviour is now adopted by
opm-parser.
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).
With this commit the generation of built in keywords is completely
changed. The most important changes include:
1) We have autogenerated a class for each keyword in the new
ParserKeywords { ... } namespace.
2) The autogenerated classes derive from ParserKeyword, and the
default constructor will build of a fully initialized
ParserKeyword instance, i.e. the keyword used to parse the EQUIL
keyword can be instantiated as simple as:
ParserKeywords::EQUIL kw;
3) The generated keywords have built in static constants for keyword
and item names, and item default values. That way it should be
possible for the compiler to catch trivial errors like trying to
access the keyword "PoRO"; also the the access to default values
means that properties can be initialized without actually
insantiating a DeckKeyword.
4) Two new classes Generator/KeywordLoader and
Generator/KeywordGenerator have been created, with the help of
these classes the keyword generation code is significantly
simplified.
this is just the result of
```
find -iname "*.[ch]pp" | xargs sed -i "s/ *$//"
find opm/parser/share/keywords -type f | xargs sed -i "s/ *$//"
```
so if it causes conflicts with other patches, the others should get
priority. The rationale behind this patch is that some people tell
their editor to remove white space which leads to larger than
necessary patches...
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.)
Parser::hasKeyword() was called with deckNames but looked up the map
for internal names. This patch renames the method to hasDeckName(),
renames Parser::getKeyword() to Parser::getKeywordFromDeckName() and
adapts/extends the tests.
Surprisingly, some compilers (notably GCC 4.6.3) will issue a warning
when comparing a literal which is clearly positive to an unsigned type,
when looking for a suitable instantiation in Boost. This is fixed by
making the literal unsigned too, so there's no doubt.
