This only occurs for generic systems with a Log failure mode.
#[sysfail(Log<GizmoError<T>>)]
fn drag_gizmo<T>(time: Res<Time>)
where
T: std::fmt::Debug,
This is because in sysfail, we special-case Log to generate a static similar to how the info!, debug! etc macros from the tracing crate works. The problem is that we use the Log's parameter (here GizmoError<T>) to determine the log level of the error (specifically this line in generate.rs: <#ret_type as #prefix::Failure>::LEVEL).
This is a fundamental limitation of rust, we simply can't (yet) use generics parameters in static or const value expressions.
Partial fix
For Log specifically, the level is declared as the second type parameter of Log, so we should be able to select (though the is_log check accepts any arbitrary type) the error type directly from it, and not need to include the generic parameter in the static expression.
Workarounds
Erase the return generic parameter. In this example, GizmoError could potentially avoid having a T parameter.
Use a Failure mode type that doesn't have the Log text in its name.
This only occurs for generic systems with a
Logfailure mode.This is because in
sysfail, we special-caseLogto generate astaticsimilar to how theinfo!,debug!etc macros from thetracingcrate works. The problem is that we use theLog's parameter (hereGizmoError<T>) to determine the log level of the error (specifically this line in generate.rs:<#ret_type as #prefix::Failure>::LEVEL).This is a fundamental limitation of rust, we simply can't (yet) use generics parameters in
staticorconstvalue expressions.Partial fix
For
Logspecifically, the level is declared as the second type parameter ofLog, so we should be able to select (though theis_logcheck accepts any arbitrary type) the error type directly from it, and not need to include the generic parameter in the static expression.Workarounds
GizmoErrorcould potentially avoid having aTparameter.Failuremode type that doesn't have theLogtext in its name.