tree 8f37e7ab109e4daf9467016818bcb4cf94ffdfc6
parent 9ae8cc43710a9b4c67b91722b937e87725dda7cb
author Václav Kubernát <kubernat@cesnet.cz> 1585168306 +0100
committer Václav Kubernát <kubernat@cesnet.cz> 1585224895 +0100

Rework leaf_data

The previous implementation of leaf_data used a grammar, where all of
the leaf_data_* parsers were tried one after another and then in each of
their on_success handlers, the type of leaf was checked against the
attribute of the parser. This leads to two problems:
1) Ambiguity. Example: 1 can be parsed as any of the integral parsers.
This can lead to a problems inside the parser (ambiguity is the reason
the parser doesn't work in newer Boost versions).
2) Order of the alternatives. Because the alternative parser can only be
defined at compile-time, there is no way to change the order of the
alternatives. Right now, this isn't a problem, since a leaf can only
have one type, but I'm going to need a way to reorder the parsers to
implement unions.

The new leaf_data parser is implemented by creating an entirely new type
of parser. A parser (as far as Spirit is concerned) is a class that
inherits from x3::parser and implements parse(), which returns whether
the parser passed or not. In this method I have access to ParserContext.
That means I can dynamically choose which parser is going to be used
according to the return value of Schema::leafType.

Another advantage is that now I don't need on_success handlers for basic
types and I can use the elemental parsers directly. Types like enum need
extra validation, so they keep their handlers. If I ever need extra
validation on more types, I can easily add some of the handlers back.

I also moved the createSetSuggestions handler to leaf_data.hpp since
it's directly connected to leaf_data (even the rule is defined in this
file).

Side note: the parser could have been implemented by using an
implementation of the lazy parser from here
https://github.com/boostorg/spirit/issues/530.
However, a Spirit developer suggested I just inherit from x3::parser and
use that.

Side note 2: all of the completion creators can be implemented in a
similar way, and that brings some advantages too.

Side note 3: the parser for paths can be rewritten in a similar way to
this, but right now it's not needed. When Boost gets updated, the
rewrite will happen then.

Change-Id: Ia29c1895833b811a45873f8490da9c64fa4742eb