Automatically detected by clang-tidy with performance-move-const-arg check.
Do not make the modification for Tokenizer::location type, since we have no
guarantee that the type will remain trivially-copyable in the future.
Automatically detected using clang-tidy with bugprone-reserved-identifier
check.
By the way, homogeneize the define identifiers in relation to camel case
convention.
This is unsafe since the find() method can return a past-the-end iterator,
which should be tested for.
Replace most instances by calls to the std::map::at() method (which throws if
the key is unknown), and which is incidentally more readable.
In particular, use this feature in many loops which feature a special treatment
for the first iteration, using a boolean variable (replacing iterator
manipulation). By the way, also use std::exchange() to simultaneously test the
value of this variable and update it.
We follow the advice given by Josuttis in his book about move semantics.
Deleting those member fuctions can be a bug if we want to allow copy semantics,
because overload resolution will no longer fallback to the copy
constructor/assignment operator when given an rvalue.
In particular, this explain why it was not possible to delete the move
assignment operator of the StaticModel class.
The support for empty files at the macro-processor level, as implemented in
1291320053, was relying on
basic_streambuf::in_avail(), which does not seem to behave consistently across
platforms, and which may not be the right tool for the job.
Rather use the Bison grammar to support empty files.
Closes: #93
There were two bugs:
– with the LF convention, newlines were counted twice
– with the CR+LF convention, they were counted four times (because the CR was
included in yyleng, alongside the LF)
The fix consists in implementing a location_increment() method similar to the
one used for the Dynare parser. This is the most robust solution.
By the way, mark the method DynareFlex::location_increment() method static.
If the input .mod file uses CR+LF convention, and if the user is under Windows,
then the output of the macroprocessor (as given by the “savemacro” option) had
incorrect end of lines: those would be CR+CR+LF.
The reason is that some TextNode(s) internally created by the macroprocessor
would themselves contain CR+LF sequences, which would then be transformed into
CR+CR+LF in the output (because MinGW transforms LF into CR+LF in output
streams).
The fix consists in changing the nature of the EOL token: the parsed text is no
longer attached to it, so that the Bison file now systematically turns it into
a LF inside TextNode(s).
Closes: #80
This only concerns the situation when `savemacro` is also passed.
When `linemacro` is passed, the macro expanded .mod file is the same as before
When `linemacro` is not passed, the macro expanded .mod file is equivalent to what it was before when both `noemptylinemacro` and `nolinemacro` were passed.
closes#44closes#45
Sébastien Villemot
Houtan Bastani