Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp918504iob; Wed, 4 May 2022 10:37:13 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz+ClLa3P2v4kgvlnuXAAs9XKYJMxx37oRoXEaP6371XGhoT6f1SAc/AupEQu40sNiFgyvo X-Received: by 2002:a63:4412:0:b0:3a9:e7e1:81a6 with SMTP id r18-20020a634412000000b003a9e7e181a6mr18496488pga.532.1651685832770; Wed, 04 May 2022 10:37:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651685832; cv=none; d=google.com; s=arc-20160816; b=MZoZ3oBDOjkRJaymabJe/+1N/VlBmvPjXhDlmZ7+2fTcopYiUJg1xV4aaSXRrwYfDH EzsnJEB6Jj08xEmVC6huJAYF0zLEo3dXqyKIH4WzusiM/heZxd9Ga2hWuYiUKA/KDBRr OCWTCBvDEn5VcVHZ9w/Rarrr2N1+yVvnJLvl2708HYTxKjb3i4RpOxdF0gG4tepKu9QL h9caRnvuieEm0UiT7fywdoR5MU3iZ5ZM1u2dePvhu6PqKZV22eyxo3HejyZD6P/C0AWK Rttvrgb0ZSvG9Oqy46+BHzgPdbXcPC3BPcjm7AFTiwNFmbrYlfff4B4UyWigSsUJWR1E oRlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=7s8Dkq+WYTUvt1eMI+UndBL7YVh+xKQ8rqnLmZXLwkY=; b=BlsX4YcJGDkFjWmH7zx0cdD0tIrB+QlaujzYmb8NfYI5uPorugsYMeBzB3sVFwMp+t 2gPBrunNXp3+ApZIRM5GrpuQTUt+6tuZpsEi7mIkOQR4PSL2IZx3V+vP9E56ktsLzb/+ Ge/u5MxzPWnzLKq6z9htnAz/lvAHopA59tZ62xtMSP/So2a9dJx5ABcl8ZZZL/u6T6Fw 3oG5EDi4b0EPyfvMjUmQJWdLLyuW7O/hyut6muKvIFjoSKl+rF8s7hrv70nkaeKGDSyP GAzyg7VXqJO94jt3r3Aye1AnDpTH03jp6awgmnc5UYhS1rb6+L6PWwre0AAdUap7T6YG iSHA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=OyGdp78b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l63-20020a639142000000b003aba3e87b34si20109933pge.124.2022.05.04.10.36.55; Wed, 04 May 2022 10:37:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=OyGdp78b; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351115AbiEDOJy (ORCPT + 99 others); Wed, 4 May 2022 10:09:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54496 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351109AbiEDOIs (ORCPT ); Wed, 4 May 2022 10:08:48 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CBF73FDBD for ; Wed, 4 May 2022 07:05:10 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id c190-20020a1c35c7000000b0038e37907b5bso3305673wma.0 for ; Wed, 04 May 2022 07:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7s8Dkq+WYTUvt1eMI+UndBL7YVh+xKQ8rqnLmZXLwkY=; b=OyGdp78bqxqrVMr3zdt1uaD/Ac3z6RgQidnw+5ULB1bz2kwC5QjwLR4rSRoFkSTM47 50juL7UMKQsOV4WPjGDT5GGOLdyvS2YnnaPx0yPDhjoadetCqTUGgcPxI5D6ZMYGOND4 0XNkHMMApj3HLIC+7ebffNsggdfjA7Sg/nbTNuWO2U7IqLyjyTzOeYFwmYI81uRe7pes ybW/4+E5QLmlj8OZtVek7tuz2VOVX9dGqBmHibaKp/vlmzT/ngytIkDTPO1HzjlEOfjr Us3SRmbZxBjfofrJnBdGg0tIMBs9TOUD4pH7i+0qcuTyfcP1u613zaJAjN4gEjI56Ti4 /kfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7s8Dkq+WYTUvt1eMI+UndBL7YVh+xKQ8rqnLmZXLwkY=; b=IDgtI8FMaxB44OhKvZOj68C+t0tBMXmDTot028P6FqMCZ8T7uV8wiKACM+BpSvaxGs RovY8j28KovNRPL+OMWj5XLUwCwUNE3W+3HgLlcx7w70a7mXq+nwroHVUdvnLgymqXL9 U269ZiKNv6DfxK4aU0ULpCJe/DbOZhDg/nhWwjJ6R6Jxbo9WTWpY4IcjT477sWq27XCp yABMankgOEmqu4CypkndWRQCL8U/qqHOP/MEnNyEz6i0zLerh2vklTfiXjW/kfSDBwEC qSXNThLp8gQ/wLpAIjc+yX8QYZ99Rmfr60nBeXx31lh1ktJWN2Jt2d8QSemk8gS46tnR KVPg== X-Gm-Message-State: AOAM530GY68lrzNFdDlIKCHT1PgZI4HaAVOIJcmCvB+XRymWIbQRtsDg bGlOoUJF66fS8OZBgN7ddn2Iv3n/+qHen6X03bjb7g== X-Received: by 2002:a05:600c:264e:b0:394:2c56:eeb5 with SMTP id 14-20020a05600c264e00b003942c56eeb5mr8098997wmy.6.1651673108864; Wed, 04 May 2022 07:05:08 -0700 (PDT) MIME-Version: 1.0 References: <20220502093625.GA23225@kernel.org> In-Reply-To: From: David Gow Date: Wed, 4 May 2022 22:04:57 +0800 Message-ID: Subject: Re: [PATCH] kunit: take `kunit_assert` as `const` To: Miguel Ojeda Cc: Daniel Latypov , Miguel Ojeda , Brendan Higgins , "open list:KERNEL SELFTEST FRAMEWORK" , KUnit Development , linux-kernel Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 4, 2022 at 4:09 PM Miguel Ojeda wrote: > > Hi Daniel, > > On Mon, May 2, 2022 at 9:44 PM Daniel Latypov wrote: > > > > Reviewed-by: Daniel Latypov > > > > Thanks for this, the code definitely should have been this way from the start. > > > > I had wanted to make this change but mistakenly thought the format > > func took it via non-const for some reason. > > I must have misread it once and got it into my head that we were > > leaving the door open for mutable child structs (which sounds like a > > bad idea). > > Thanks for reviewing it so quickly! Yeah, I was unsure too if there > was an external reason such as some future plan to use the mutability > as you mention or maybe some out-of-tree user was relying on it > already. > > But I thought it would be best to make it stricter until it is > actually needed (if ever); or if there is an actual user for > mutability, it should be documented/noted in-tree. I definitely agree here -- I can't recall any particular plan that would require this to be non-const, and we can always change it back if we really need to. > It also simplifies a tiny bit a Rust-side call to > `kunit_do_failed_assertion` that I am using within generated Rust > documentation tests. Very exciting! I assume that's the PR here: https://github.com/Rust-for-Linux/linux/pull/757 Cheers, -- David