Received: by 2002:a05:6a10:8a4f:0:0:0:0 with SMTP id dn15csp2601494pxb; Mon, 31 Jan 2022 03:41:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwDOMrGCDQBVda6wPxKCczJB5NbRtIa/daPwH44l/IpHcsfTqp+lS8dkye9cl2CATfQIzU X-Received: by 2002:a17:90b:4d8d:: with SMTP id oj13mr33819828pjb.238.1643629313961; Mon, 31 Jan 2022 03:41:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643629313; cv=none; d=google.com; s=arc-20160816; b=YLnJswF0UuKTEzNRFLP1Fp1gpenLrKC6hrdUAeRlNj3MaCXkQn7MkToA/sYEgqI8qp lmcZpczJlQCobS5Nlp/3fPEjjh1ODRm08aSVpNarrRqjQpNT4vJL4xn3ZlU5UF5UkGln k+UN94pgNx3EFDOlAEB3rm/3DjFLpV9NeUCErwgNxf+exyLJwM5n8qgNImWndZwicS8m r0QlXXMOcKGS3LKVpwTJdCqQpwwzA2+GJ3g5l7dQT8WcZ5uI0HWETvFKsuJnME1jpg+W DS9MDvfxZAjon7NovVDmhwK5cb+r6mvIK/8XICiJm0sHEpMAm5mB1fNjMUaFwOAUSVsS TRyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=CUuoA1H1xCLa0a1bVW4NlOMKpUawKO6N9kfvmo3RGOM=; b=sGSQWlJijo3ul0NLXO70k0XWRqThmklqmXDNNevxmAJuREO6n+5c6tI6Jey6do0TxL fqMlP62j/3zBWNNLAY3qX8YCLQ/WRscRcylC/jKEb8Ail6WR1sxb7JvyMskOQxnrhRn8 lrE560idVhC+w+NiGqECDsB1KPCPpaBPqAKRbWFHTUP09qZ8DClbeCWhgJ03pf1CA8bE TI7iZC1BIHxYEfg+Qi3P9NTwRtn701pPsHEJmSA82UMN2br2eGT8wWbXSN2y/PoFY7Mn hWTDx8h4EeOtJE1H3Qp44Wb5hw/vB+3JPWaiIubE8a+NkBNNISbd7zCTa+ukLf8fHNWh J3Qg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=U4gZi4VC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d73si13301536pga.811.2022.01.31.03.41.43; Mon, 31 Jan 2022 03:41:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=U4gZi4VC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1351541AbiA1VhK (ORCPT + 99 others); Fri, 28 Jan 2022 16:37:10 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56740 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351511AbiA1VhJ (ORCPT ); Fri, 28 Jan 2022 16:37:09 -0500 Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id DBDB7C06173B for ; Fri, 28 Jan 2022 13:37:08 -0800 (PST) Received: by mail-ej1-x62f.google.com with SMTP id j2so20128841ejk.6 for ; Fri, 28 Jan 2022 13:37:08 -0800 (PST) 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:content-transfer-encoding; bh=CUuoA1H1xCLa0a1bVW4NlOMKpUawKO6N9kfvmo3RGOM=; b=U4gZi4VClu3Fy3b0MUuy+OH+FPtbaikctEYX0ZAeCHxIky1wQ3Bv9sLZYdRg3sg8jn gQ1TXW9cQQmRIce4Ur/I/oZRJXONbWQcitCi62NNG88NPyiRR+VM+o4JLs4Dq6pKlLfV AcoEjvvNLllQuFcBUmosqPuyp+bqe3K28zBRwUKVQwN21sapCudCqhEcwXysEXBsV7MM sqaSGvuY3gaejvqSaltDVaWFAfdhdJzBPwug1N3YFxZG1jE3HY3ZSB96jaV2sot9rL4T Lk2G8s1Xc7Kjce44nsgXExVd/IwlbhuqsTeJYKLhn2asN1FSNCIKYWjURZbpdZ/y/6m3 +bww== 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:content-transfer-encoding; bh=CUuoA1H1xCLa0a1bVW4NlOMKpUawKO6N9kfvmo3RGOM=; b=OJpYIa/aek0zPCc58HIFc7BBxibkIk9vojit+dxQoaNaq6Xe8IcD/lDhI6FKhyWv6Q /MFZelURl6+6Bw/+dmKsUCE4g/BXoCYSBOhKsXNFt/428OJ0TJWi18EyssffqeOSFLTq Dry70hryH6BCnB2Ge8IHvEvBMPZxw8kJ1+T8qZZfosv/tDLrJje+TGIjCE++2Vs77FbN HR6kWN3iNo1O8z3sT82JDAUbHjah3QtLdlP4PSxj8qXP3wPls1fBbt5dKlcP7SUPWrpi fLQjChPs38/4An1qiAU3UI+4plljHt4Ao2IuY4MjafoR1HXbXzpEk+ZA+veDYkjP1MzM 2G6g== X-Gm-Message-State: AOAM532pfRSukP4mZTwnCr9qhfklKhcBmgbj4bj8k0B2d/hLeRgIwqP1 pFj6fUiWhyQ9psD1SAKIAh4ekQvT/onIRWzWirnW93o7qV9paA== X-Received: by 2002:a17:906:794f:: with SMTP id l15mr8765287ejo.75.1643405827189; Fri, 28 Jan 2022 13:37:07 -0800 (PST) MIME-Version: 1.0 References: <20220127215222.159049-1-dlatypov@google.com> In-Reply-To: From: Daniel Latypov Date: Fri, 28 Jan 2022 13:36:55 -0800 Message-ID: Subject: Re: [PATCH] kunit: cleanup assertion macro internal variables To: Brendan Higgins Cc: davidgow@google.com, linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, skhan@linuxfoundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 28, 2022 at 1:21 PM Brendan Higgins wrote: > > On Thu, Jan 27, 2022 at 4:52 PM Daniel Latypov wrot= e: > > > > All the operands should be tagged `const`. > > We're only assigning them to variables so that we can compare them (e.g= . > > check if left =3D=3D right, etc.) and avoid evaluating expressions mult= iple > > times. > > > > There's no need for them to be mutable. > > Agreed. > > > Also rename the helper variable `loc` to `__loc` like we do with > > `__assertion` and `__strs` to avoid potential name collisions with user > > code. > > Probably not necessary since we create a new code block (we are inside > of an if-statement, do-while-loop, etc), but I don't really care > either way. You're totally right that this doesn't matter with our current macros. given int loc =3D 42; KUNIT_EXPECT_TRUE(test, loc); KUNIT_EXPECT_EQ(test, loc, 42); becomes do { if (__builtin_expect(!!(!(!!(loc) =3D=3D !!true)), 0)) { /* we don't use the operands in here, so `loc` is fine */ static const struct kunit_loc loc =3D { .file =3D "lib/kunit/kunit-example-test.c", .line = =3D 25 }; ... do { typeof(loc) __left =3D (loc); typeof(42) __right =3D (42); do { /* We never reference the expression again, so `loc` is fin= e */ if (__builtin_expect(!!(!(__left =3D=3D __right)), 0)) { static const struct kunit_loc loc =3D { .file =3D "lib/kunit/kunit-example-test.c", .line =3D 24 }; But reminder: this was *not* the case until very recently. Sau we didn't have my earlier patch to move the `if(!(passed))` check into the macro. Then we'd have issues, e.g. ../lib/kunit/kunit-example-test.c: In function =E2=80=98example_simple_test= =E2=80=99: ../include/kunit/test.h:828:26: error: wrong type argument to unary exclamation mark 828 | !!(condition) =3D=3D !!expected_true, \ | ... ../lib/kunit/kunit-example-test.c:25:9: note: in expansion of macro =E2=80=98KUNIT_EXPECT_TRUE=E2=80=99 25 | KUNIT_EXPECT_TRUE(test, loc); | ^~~~~~~~~~~~~~~~~ So being defensive here lets us change up our implementation more freely. > > > Signed-off-by: Daniel Latypov > > Reviewed-by: Brendan Higgins