`Option<T>` parameters in `poise::command` function cause exponential compile times

[calebberhow]

Description

Given a command like with many Option<T> parameters, the poise::command proc-macro leads to exponentially increasing compilation times for commands with more parameters. This affect does not occur for non-optional parameters.

Expected behavior

Functions with the poise::command proc macro should compile in a reasonable amount of time, or there should be an explicit upper limit on the number of parameters allowed.

Current Behavior

Below are some data from my testing

Test Case	cargo check time
12 String params	0.22s
8 Option<bool> params	0.22s
9 Option<bool> params	6.4s
10 Option<bool> params	27.51s
8 Option<String> params	0.22s
9 Option<String> params	25.5s
10 Option<String> params	2m 57s

Steps to reproduce

Write a function like the following and witness cargo check take a very long time to complete.

See minimum reproducible example repo for full project.

#[poise::command(slash_command, prefix_command)]
pub async fn test(
    _ctx: poise::Context<'_, (), Box<dyn std::error::Error + Send + Sync>>,
    _param1: Option<String>,
    _param2: Option<String>,
    _param3: Option<String>,
    _param4: Option<String>,
    _param5: Option<String>,
    _param6: Option<String>,
    _param7: Option<String>,
    _param8: Option<String>,
    // Warning: long compile times, may stall out rust extension
    _param9: Option<String>,
    // Warning: extremely long compile times, may stall out rust extension
    // _param10: Option<String>,
    // Warning: doesn't compile on my machine, as it runs out of memory (20+ GB RAM usage).
    // _param11: Option<String>,
) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    Ok(())
}

Testing environment

Operating system: Windows 11
CPU architecture: x86-64
Cargo version: cargo 1.92.0 (344c4567c 2025-10-21)

[KiloOscarSix]

Does this happen if you only have slash_command? #[poise::command(slash_command)]?

[calebberhow]

Does this happen if you only have slash_command? #[poise::command(slash_command)]?

No, this only appears when using prefix_command. Sorry, my minimum reproducible example should not have had slash_command

[KiloOscarSix]

No problem, just confirms my suspicion that this is rooted in parsing the message and the deep branching for optional arguments

[mkrasnitski]

@calebberhow Which release of poise are you using? Are you using a version from crates.io or a git dependency (if so, what branch)?

[calebberhow]

@mkrasnitski Version 0.6.1 from crates.io

[mkrasnitski]

Alright, so the responsible code is likely this:

poise/src/prefix_argument/macros.rs

Lines 14 to 35 in 518ff05

	// Consume Option<T> greedy-first
	( $ctx:ident $msg:ident $args:ident $attachment_index:ident => [ $error:ident $($preamble:tt)* ]
	(Option<$type:ty $(,)?>)
	$( $rest:tt )*
	) => {
	// Try parse the next argument
	match $crate::pop_prefix_argument!($type, &$args, $attachment_index, $ctx, $msg).await {
	// On success, we get a new `$args` which contains only the rest of the args
	Ok(($args, $attachment_index, token)) => {
	// On success, store `Some(token)` for the parsed argument
	let token: Option<$type> = Some(token);
	// And parse the rest of the arguments
	$crate::_parse_prefix!($ctx $msg $args $attachment_index => [ $error $($preamble)* token ] $($rest)* );
	// If the code gets here, parsing the rest of the argument has failed
	},
	Err(e) => $error = e,
	}
	let token: Option<$type> = None;
	// Parse the next arguments without changing the current arg string, thereby skipping the
	// current param
	$crate::_parse_prefix!($ctx $msg $args $attachment_index => [ $error $($preamble)* token ] $($rest)* );
	};

However, this macro is pretty unreadable and has been removed on the next branch, where all the parsing code is now generated inside the attribute macro. When I rewrote the parser-generating code, I intentionally made sure to keep the generated code the same by comparing the outputs of cargo expand in order to avoid any regressions. So, the performance problem likely also exists on next, with the responsible code being:

poise/macros/src/command/prefix.rs

Lines 204 to 223 in e9d706b

	if let Some(ty) = unwrap_generic(ty, "Option") {
	// Greedily parse `Option<T>` by first trying to parse for `Some(T)`. If that fails, try
	// again with `None` instead.
	quote::quote! {
	match <#ty as ::poise::PopArgument>::pop_from(
	&args,
	attachment_idx,
	serenity_ctx,
	msg
	).await {
	Ok((args, attachment_idx, token)) => {
	let #token: Option<#ty> = Some(token);
	#parsed_rest
	}
	Err(e) => error = e,
	}
	let #token: Option<#ty> = None;
	#parsed_rest
	}
	} else if let Some(ty) = unwrap_generic(ty, "Vec") {

Using the latter as a reference, note that #parsed_rest contains the recursively generated parsing code for all parameters after the current one, and also note that it is interpolated twice. This will lead to exponential growth in the amount of generated code. We can verify this by looking at the output of cargo expand on your repro and seeing that the number of lines roughly doubles with each extra function parameter. So, we can solve this by figuring out a way to interpolate parsed_rest only a single time.

[CalebBe-2253]

I ran cargo expand on the example repo for the 0.6.1 version and the next branch. They both exibit this doubling behavior for each added parameter.

No. Parameters	cargo expand output lines (crates.io 0.6.1)	cargo expand output lines (next branch)
5	858	834
6	1412	1858
7	3494	3554
8	6872	7042
9	13826	14242

The vast majority of lines are within the prefix action function.