From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id D0B761FF0AA for ; Fri, 04 Sep 2026 09:19:21 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 86C9621575; Fri, 04 Sep 2026 09:19:21 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Sep 2026 09:19:16 +0200 Message-Id: Subject: Re: [PATCH proxmox v5 03/21] api-macro: support #[state] attribute for state injection From: "Lukas Wagner" To: =?utf-8?q?Michael_K=C3=B6ppl?= , "Lukas Wagner" , X-Mailer: aerc 0.21.0-0-g5549850facc2-dirty References: <20260903111609.267762-1-l.wagner@proxmox.com> <20260903111609.267762-4-l.wagner@proxmox.com> In-Reply-To: X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1788506352769 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.477 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 5JYOH7IOUFKIWWQE6LTOSUUF3DCDB3WQ X-Message-ID-Hash: 5JYOH7IOUFKIWWQE6LTOSUUF3DCDB3WQ X-MailFrom: l.wagner@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Datacenter Manager development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Thu Sep 3, 2026 at 8:51 PM CEST, Michael K=C3=B6ppl wrote: > On Thu Sep 3, 2026 at 1:15 PM CEST, Lukas Wagner wrote: > > [snip] > >> fn handle_function_signature(method_info: &mut MethodInfo) -> Result { >> + let state_params =3D take_state_attributes(&mut method_info.func.si= g); >> + >> let sig =3D &method_info.func.sig; >> =20 >> let mut api_method_param =3D None; >> @@ -382,7 +474,11 @@ fn handle_function_signature(method_info: &mut Meth= odInfo) -> Result> =20 >> let mut param_list =3D Vec::<(FieldName, ParameterType)>::new(); >> =20 >> - for input in sig.inputs.iter() { >> + for (index, input) in sig.inputs.iter().enumerate() { >> + if state_params.contains(&index) { >> + continue; >> + } > > Even though it's not something that would likely occur (since this would > e.g. occur if someone used `#[state] _: PdmApplication` or something > similar), this would not show any errors from checking the types > anymore, no? Because the second [loop] expects errors to be handled > [here], but for state params, this check would simply be skipped. Hope > I'm not missing something here, but this would probably hide errors. > Good thinking! I tried various patterns, such as=20 #[state] _: A #[state] A(inner): A #[state] B {inner}: B and they don't work with the API macro, it seems to trip up somewhere else - so the issue you described does not seem to matter here. Now, the next question is, should these patterns work for #[state] arguments? Probably fine if they don't, but long-term we could think about supporting these - at least the last two could be handy in some cases. But we'll probably get by fine without them. >> + >> let (pat_type, pat) =3D match check_input_type(input) { >> Ok(input) =3D> input, >> Err(err) =3D> { > > [here] > >> @@ -410,7 +506,7 @@ fn handle_function_signature(method_info: &mut Metho= dInfo) -> Result> }; >> } >> =20 >> - for input in sig.inputs.iter() { >> + for (index, input) in sig.inputs.iter().enumerate() { >> let (pat_type, pat) =3D match check_input_type(input) { >> Ok(input) =3D> input, >> Err(_err) =3D> continue, // we already produced errors abov= e, > > [loop] > >> @@ -421,17 +517,20 @@ fn handle_function_signature(method_info: &mut Met= hodInfo) -> Result> // values, and our 2 fixed function parameters: `&ApiMethod` an= d `&mut dyn RpcEnvironment`. >> // >> // Our strategy is as follows: >> - // 1) See if the parameter name also appears in the input s= chema. In this case we >> + // 1) See if the parameter was marked with `#[state]`. Such= parameters are filled in > > [snip]