Repository navigation
Handle ?eval code generation differently #26
Description
Activity
- changed the title
[-]Handle ?eval output differently[/-][+]Handle ?eval code generation differently[/+]on Dec 31, 2020 Naively splitting by semicolons would break quite quickly, for example when putting semicolons in colons or in strings. A more robust way would be to parse the source code using something like syn. This brings plenty problems though:
- how to exactly preserve the user's code formatting when deserializing from syn data structures to Rust code text?
- how to handle parse errors? Syn won't display the nice error message we know from rustc, so we'd probably have to run the code through rustc first, just to catch any syntax or parse errors, then through syn to add the proposed issue behavior, then again through rustc to actually compile and run
This all seems quite clunky and error prone. Does someone have an idea how to do it better?
Problem
Currently, the code provided to the
?evalcommand is wrapped like this:This has a small issue; when the code evaluates to a value with a lifetime, the code fails to compile, for example:
That's because
&aexits the scope we explicitly declared with {}, but its lifetime is bound to something within that scope (a).This is slightly confusing for bot users and also a bit annoying.
How to fix
You may be able to prevent this issue by wrapping the code differently. The following ?eval input...
...would be translated to the following Rust code...
In other words: the code will be split up by semicolons and only the result of the last line is put into the
println!(). The rest are top-level statements inside main.I'm not sure if there are edge cases in which this approach would break