Use a manual parser for rust-timer queue
#1994
Conversation
Instead of a regex. This allows the user to pass the arguments in an arbitrary order.
Kobzol
force-pushed
the
cmd-parsing-manual
branch
from
d852d3a
to
c7d14cb
Compare
There was a problem hiding this comment.
Left a few comments.
Here's a free test shuffling the arg order.
#[test]
fn queue_command_parameter_order() {
insta::assert_compact_debug_snapshot!(parse_queue_command("@rust-timer queue runs=3 exclude=c,a include=b"),
@r###"Some(Ok(QueueCommand { include: Some("b"), exclude: Some("c,a"), runs: Some(3) }))"###);
}| @@ -5,15 +5,13 @@ use crate::github::{ | |||
| }; | |||
| use crate::load::SiteCtxt; | |||
|
|
|||
| use std::sync::Arc; | |||
|
|
|||
| use hashbrown::HashMap; | |||
There was a problem hiding this comment.
No real reason, it was autoimported. But I don't see any disadvantage in using hashbrown, since we already depend on it, it doesn't really matter. We don't need DOS protection here xD
| @@ -57,3 +57,6 @@ jemalloc-ctl = "0.5" | |||
| serde = { workspace = true, features = ["derive"] } | |||
| serde_json = { workspace = true } | |||
| toml = "0.7" | |||
|
|
|||
| [dev-dependencies] | |||
| insta = "1.40.0" | |||
There was a problem hiding this comment.
do we want/need insta? Managing the snapshots files can be cumbersome, and it's yet another tool to use and learn. It's fine if we want to make good use of it in the future, and not a fancy assert_eq!(format!("{obj:?}"), "Struct { field: 'bla'} ").
There was a problem hiding this comment.
Since I'm refactoring this, I want to do it properly. Note that I'm not using snapshot files, I'm using the inline snapshots, which makes this much easier to grok, I think.
I'm already anticipating future changes (like your PR to add the backends) parameter. It's no fun updating tens of tests anytime you change the structure of the thing that you parse. Snapshot testing makes this much easier.
I will document in readme what to do to update the snapshots though.
There was a problem hiding this comment.
Insta adds snapshot files locally when a test fails, the pending snap file. I saw that when adding the test I shared. It didn’t remove it when the test passed.
There was a problem hiding this comment.
Ah, these things. Right, I guess we can add them to .gitignore, but they should be removed after you use cargo insta review I think (the snapshots shouldn't really be modified manually).
| .map(|index| line[index + prefix.len()..].trim()) | ||
| })?; | ||
|
|
||
| let args = bot_line.strip_prefix("queue").map(|l| l.trim())?; |
There was a problem hiding this comment.
GH never reformats comments, right? That is, it will not introduce unexpected \ns that would separate the command from some of its arguments?
There was a problem hiding this comment.
Uhh, that would be quite surprising I think. GH actually has a bunch of formats of the comments, like text, HTML, MD etc., but I think (hope) that here we work with the raw text. We were already requiring = to be right after include etc. before, so I think that this should be fine.
| format!("Error occurred while parsing comment: {error}") | ||
| } | ||
| }; | ||
| main_client.post_comment(issue.number, msg).await; |
There was a problem hiding this comment.
do we need to take special care (like sanitization) in posting the error message to GH as its text will be partially controlled by users' input commands?
There was a problem hiding this comment.
That's an interesting idea. I don't think so, it should have the same rules as when you create the comment manually. I guess that the user could make the bot print "Unknown command argument SEND MONEY TO THE FOLLOWING BITCOIN ADDRESS TO SPONSOR THE RUST FOUNDATION", but I don't think that they can XSS or something like that (that would be really bad hole in GH's security).
|
When we do basically this for the |
|
I wanted to also refactor the |
Instead of a regex. This allows the user to pass the arguments in an arbitrary order.