How to handle heterogeneous optional fields

[VorpalBlade]

I'm parsing a file format (tmpfiles.d from systemd as it happens) and the format consists of lines of 7 heterogeneous fields and all but the first two are optional. For example, all of the following are valid:

L /some/path - - - - /some/other/path
C /just/some/path
C /just/some/path 755
C /just/some/path 755 -
# and so on

So far my main parser looks like this, and can handle the full line format:

fn directive(i: &mut &str) -> PResult<Line> {
    let entry_type = any_string.context(StrContext::Label("entry type"));
    let path = any_string.context(StrContext::Label("path"));
    let mode = mode_parser.context(StrContext::Label("mode"));
    let user = id_parser.context(StrContext::Label("user"));
    let group = id_parser.context(StrContext::Label("group"));
    let age = optional_string.context(StrContext::Label("age"));
    // Type of argument depends on entry type, parse in a higher layer where we untangle the multitude of modifiers entry type has
    let argument = optional_string.context(StrContext::Label("argument"));

    (
        entry_type, space1, path, space1, mode, space1, user, space1, group, space1, age, space1,
        argument,
    )
        .map(
            |(entry_type, _, path, _, mode, _, user, _, group, _, age, _, argument)| Directive {
                entry_type,
                path,
                mode,
                user,
                group,
                age,
                argument,
            },
        )
        .parse_next(i)
}

/// Low level parser that doesn't make a difference between entry types
#[derive(Debug, PartialEq, Eq)]
pub(super) struct Line {
    entry_type: String,
    path: String,
    mode: Option<Mode>,
    user: Option<Id>,
    group: Option<Id>,
    age: Option<String>,
    argument: Option<String>,
}

I could write this with alt and define 5 different alternatives, one for each possible shortening of the line, but that seems quite cumbersome. I would also assume it lacks performance somewhat. Is there a better way to do this?

[epage]

Not to sure of the schema but it sounds like you can use dispatch! to pick a parser based on the first letter.

[VorpalBlade]

Unfortunately no, some of the fields have default values. For example L specifies a symbolic link, with the last field being the target of the symlink. If the target is not given it defaults to the same path under /usr/share/factory.

All the other fields (modes, user, group and "delete if older than") also have default values.

In addition the first field is annoying as it contains modifiers such as ! (only apply at boot), other modifiers like + are specific to the type (and is not valid for all types).

The modifiers can come in any order, including before the type specifier. That is why I plan to do a two level parsing, just parsing the common parts of the format with winnow and then having custom dispatching on top.

[VorpalBlade]

This seems to work:

fn flattener<T>(e: Option<(&str, Option<T>)>) -> Option<T> {
    e.map(|(_, arg)| arg).flatten()
}

fn directive(i: &mut &str) -> PResult<Directive> {
    let entry_type = any_string.context(StrContext::Label("entry type"));
    let path = any_string.context(StrContext::Label("path"));
    let mode = mode_parser.context(StrContext::Label("mode"));
    let user = id_parser.context(StrContext::Label("user"));
    let group = id_parser.context(StrContext::Label("group"));
    let age = optional_string.context(StrContext::Label("age"));
    let argument = optional_string.context(StrContext::Label("argument"));

    let mut parser = (
        entry_type,
        space1,
        path,
        opt((space1, mode)).map(flattener),
        opt((space1, user)).map(flattener),
        opt((space1, group)).map(flattener),
        opt((space1, age)).map(flattener),
        opt((space1, argument)).map(flattener),
    )
        .map(
            |(entry_type, _, path, mode, user, group, age, argument)| Directive {
                entry_type,
                path,
                mode,
                user,
                group,
                age,
                argument,
            },
        );
    parser.parse_next(i)
}

I have no idea if this is optimal, or possibly ends up backtracking too much.