Parse from String in a Result

[Gashmob]

Hi!

In my program I uses vfs to read a file content and then parse it using lalrpop. The problem is that vfs returns a Result<String, _> and the parse method of lalrpop takes a &str. Here the code sample:

pub type Result<T> = std::result::Result<T, Fault>;

fn parse_file(main_source_file: &vfs::path::VfsPath) -> fault::Result<Box<Expr>> {
    main_source_file
        .read_to_string()
        .map_err(|error: VfsError| Fault::from_error(Box::from(error)))
        .and_then(|content: String| {
            grammar::ExprParser::new()
                .parse(content.as_str())
                .map_err(|error| Fault::from_error(Box::from(error)))
        })
}

And the complete error:

error[E0597]: `content` does not live long enough
   --> src/build/mod.rs:46:24
    |
 44 |         .and_then(|content| {
    |                    ------- binding `content` declared here
 45 |             grammar::ExprParser::new()
 46 |                 .parse(content.as_str())
    |                        ^^^^^^^ borrowed value does not live long enough
 47 |                 .map_err(|error| Fault::from_error(Box::from(error)))
    |                                  ----------------------------------- argument requires that `content` is borrowed for `'static`
 48 |         })
    |         - `content` dropped here while still borrowed

Fault is a struct deriving Error that I use because vfs and lalrpop don't use same error types.

I've looked into multiple stackoverflow similar questions but didn't succeed to apply the answers. So I come to you hoping you have a solution.

The sources of Fault struct if needed as it seems to come from it https://github.com/Gashmob/fil/blob/0bdecc4e87346d4a5b311509a4f30f11ce7a0ab9/src/fault/mod.rs

I have a temporary fix by replacing the last map_err by (but it is not awesome and I loose error context):

.map_err(|error| Fault::from_message(format!("{error}").as_str()))

[Pat-Lafon]

I think you just need to break up the and_then part? Instead of immediately passing the Result<String, ...> to the and_then, let bind the let content = ... to a variable. This will ensure that the string sticks around after parsing/error handling

[Gashmob]

Something like that?

fn parse_file(main_source_file: &vfs::path::VfsPath) -> fault::Result<Box<Expr>> {
    let content = main_source_file.read_to_string().map_err(|error| Fault::from_error(Box::from(error)))?;
    grammar::ExprParser::new()
        .parse(content.as_str())
        .map_err(|error| Fault::from_error(Box::from(error)))
}

I got a similar error

error[E0597]: `content` does not live long enough
   --> src/build/mod.rs:51:16
    |
 49 |     let content = main_source_file.read_to_string().map_err(|error| Fault::from_error(Box::from(error)))?;
    |         ------- binding `content` declared here
 50 |     grammar::ExprParser::new()
 51 |         .parse(content.as_str())
    |                ^^^^^^^ borrowed value does not live long enough
 52 |         .map_err(|error| Fault::from_error(Box::from(error)))
    |                          ----------------------------------- argument requires that `content` is borrowed for `'static`
 53 | }
    | - `content` dropped here while still borrowed

[Pat-Lafon]

Oh I see. Fundamentally you won't be able to return a Error with a reference since it's referring to an allocation(read_to_string) which will be freed when the function returns.

So you will need to allocate the error message(convert the reference into a String) before returning like you had originally. I guess it's more of a question of if you can do this while maintaining some of this "error context". It's a little hard to figure that out without your code, but it's more of question of how you are using Fault than lalrpop(Like figuring out what the error context is which isn't clear from the question, and how you can preserve/recreate/reuse it in the map_err).

Note that there isn't as much Lalrpop can do here. We could allocate the error message/not use references but this would hurt all users and wouldn't save you anything in terms of allocation costs.

[Gashmob]

Ok thanks, I'll go back to my original solution, it is easier. And sorry that was not really related to lalrpop.