Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp749700pxb; Fri, 21 Jan 2022 02:19:54 -0800 (PST) X-Google-Smtp-Source: ABdhPJwlWi+6UoeaiNRmp8hxwQWsNz337KO2u30S1c/or8laFJaxL8iIx7ea6n9t1MZ8IMiKzbBT X-Received: by 2002:a17:902:e747:b0:14b:25fd:ce1e with SMTP id p7-20020a170902e74700b0014b25fdce1emr433639plf.84.1642760394293; Fri, 21 Jan 2022 02:19:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1642760394; cv=none; d=google.com; s=arc-20160816; b=GLTGZHi3MFHhwBkczI4DZl1Gk2RR2rXH3YBfEJNU1oQ//C+V/2M8R88eJL3QVeDWEB iCoUBSSjLgT55eER9y6CHcn4rkGfBHBcmDTsHWHOi9wM85ARbktW4QmIVZ+6y+e8WGCp 7PgHk43sCYUBQW75dGXwOWiNNaEl0r6eQfKEzOgyi9f38C31Ii8fvuwqmCuxwXaNTJTF /CchLoQrNEhKqhDkDs8MNx/qIZvTmrYgl1QiEAT+W/dTfmeh106nYhDZ31TshpGDIDmG 3z+9boAGdmHwjUA2yIvvqcuR7INjRh9jxWNUduP4aCM0LXxkY9ay/GVSUU4Oy0r0tKXR zZBg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:mime-version:message-id:date :dkim-signature; bh=wGX0SgG3zKXJcV46j/Y6+4p2WMGDSqGFtH4FJYdgcw8=; b=HeAIew4rmf+hpRrqP33WfZ0uW5CBBoAtIZylqmIwy4X5p+CWdmvUCfamChZ3hZYz/Z zOJZTBc2By/oQYT32EGjJv/JKUxvgoAz/Zsbdi+2QNwCybPLnBed4NvTzHK3r1Td/KVb LMErRUdn7+Q9r9AV+Z899Lwy15jtpRsOQekXgRRbdsW3M+aBPU125yBvLvE38JcRoDI1 2NcnGZ1PCKJB4/AsNhNRLzn6bH690DkUEitjHBOZCuVj3jAq4CsRU1SydElSvv0JOLs4 20oenrWPs6k0eN9OMnGURHQXRZt9+OMch8ciGrW2rn5DZOE/grdpWlXkP6Bu555i437l b1LA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=bwrxzsIa; 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 z5si6664357plg.70.2022.01.21.02.19.42; Fri, 21 Jan 2022 02:19:54 -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=bwrxzsIa; 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 S1350010AbiARWfV (ORCPT + 99 others); Tue, 18 Jan 2022 17:35:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350026AbiARWfO (ORCPT ); Tue, 18 Jan 2022 17:35:14 -0500 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B3E7C06173F for ; Tue, 18 Jan 2022 14:35:14 -0800 (PST) Received: by mail-yb1-xb49.google.com with SMTP id g7-20020a25bdc7000000b00611c616bc76so1048249ybk.5 for ; Tue, 18 Jan 2022 14:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:message-id:mime-version:subject:from:to:cc; bh=wGX0SgG3zKXJcV46j/Y6+4p2WMGDSqGFtH4FJYdgcw8=; b=bwrxzsIaIgt7HiTRY9vyXV7xP/3VD5epRoVBl2SdP+/tnJ4C1q+jGrvTzsgUpQkuw2 wdmY6nboth4HLo0aaUBc0u4j/LM86v9/c9R6+nK90cnh0c64ZnnZ0/mHdzqvViY5whe6 dxwRK84lQnY8miw77jclVEgmHIH+XHCzi1dYomKOrllMFppaKubPCScJPYoJPOvfVl8u CCoWekSKyl8/4ZdZxhBEbP/zR/6joAyKF644z7zPy9N6NxR+bkkii4//dEajFPrpdeaR JO9WvUpaCHgX1U9m/AN9CzESYAnmrod0qBy0X0sYGpw2WPgvIrs/dqfOPNFfzzsnDzfv Py7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=wGX0SgG3zKXJcV46j/Y6+4p2WMGDSqGFtH4FJYdgcw8=; b=aLIXz9B5GUCFbGaNESehKbfxorjDDp0T2fQjRR9eRxDvaVRmJi/bTIbw8OCV/JUyZY JL/0nmvuSGJbXyRPwoPYe7ZUBEkCwZDnYnlpDYYavsujjF9CqeDvtbEVqnRi+eFO8AdW w2i3vj3ZhtAAQtgFi8M4A9/Kmv6zdJMHfR+p5V+ngFALzQa8wGJLECDOT0K3P5PazXOc AQtaG1yCPo3mKGdTedJUFMkDsnPMPUITDTmHVnVsQO5R1ctWc8jFcd+dykT7XG7SPusU VifwPjGl3EIWkynS255CPAvd3G+TIF3pp0Bmzk0sujMkQ+0HA4WXExG5A2dAXSCRQqQn f9zw== X-Gm-Message-State: AOAM5310uZlYDrq8mH/eLmCHxPPDY9BAgeGIL8N5+6OML8T6LiQMfFa8 3RllFP32EmifRf5VWt9lxIXE5BqElh6fBw== X-Received: from dlatypov.svl.corp.google.com ([2620:15c:2cd:202:7fc9:5977:ab73:1d36]) (user=dlatypov job=sendgmr) by 2002:a25:654:: with SMTP id 81mr33640131ybg.541.1642545313426; Tue, 18 Jan 2022 14:35:13 -0800 (PST) Date: Tue, 18 Jan 2022 14:35:01 -0800 Message-Id: <20220118223506.1701553-1-dlatypov@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.34.1.703.g22d0c6ccf7-goog Subject: [PATCH 0/5] kunit: decrease layers of assertion macros From: Daniel Latypov To: brendanhiggins@google.com, davidgow@google.com Cc: linux-kernel@vger.kernel.org, kunit-dev@googlegroups.com, linux-kselftest@vger.kernel.org, skhan@linuxfoundation.org, Daniel Latypov Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Note: this series applies on top of the series reducing stack usage, https://lore.kernel.org/linux-kselftest/20220113165931.451305-1-dlatypov@google.com/ There's no real smenatic dependency between these, just potential for merge conflicts. The current layout of the assertion macros is confusing. Here's the call chain for KUNIT_EXPECT_EQ() and KUNIT_EXPECT_EQ_MSG() KUNIT_EXPECT_EQ => KUNIT_BINARY_EQ_ASSERTION => # note: not shared with the _MSG variant KUNIT_BINARY_EQ_MSG_ASSERTION => KUNIT_BASE_EQ_MSG_ASSERTION => KUNIT_BASE_BINARY_ASSERTION KUNIT_EXPECT_EQ_MSG => KUNIT_BINARY_EQ_MSG_ASSERTION => KUNIT_BASE_EQ_MSG_ASSERTION => KUNIT_BASE_BINARY_ASSERTION After this series KUNIT_EXPECT_EQ => KUNIT_EXPECT_EQ_MSG => KUNIT_BINARY_INT_ASSERTION => KUNIT_BASE_BINARY_ASSERTION The current macro layout tries hard to reduce duplication, but comes at the cost of a lot of intermediates that can simply vanish. The same call-chain again, but annotated with the info we add: KUNIT_EXPECT_EQ => specify we're an EXPECT, not an ASSERT KUNIT_BINARY_EQ_ASSERTION => specify we have a NULL msg KUNIT_BINARY_EQ_MSG_ASSERTION => specify we work with ints, not ptrs KUNIT_BASE_EQ_MSG_ASSERTION => specify that the op is '==' KUNIT_BASE_BINARY_ASSERTION We can see that each level of the chain only specifes one parameter at a time. We've taken the concept of DRY too far. The following is a full snippet of all the macros needed for KUNIT_EXPECT_EQ, showing that a bit of repetition is just fine: #define KUNIT_BINARY_INT_ASSERTION(test, \ assert_type, \ left, \ op, \ right, \ fmt, \ ...) \ KUNIT_BASE_BINARY_ASSERTION(test, \ kunit_binary_assert, \ KUNIT_INIT_BINARY_ASSERT_STRUCT, \ assert_type, \ left, op, right, \ fmt, \ ##__VA_ARGS__) #define KUNIT_EXPECT_EQ(test, left, right) \ KUNIT_EXPECT_EQ_MSG(test, left, right, NULL) #define KUNIT_EXPECT_EQ_MSG(test, left, right, fmt, ...) \ KUNIT_BINARY_INT_ASSERTION(test, \ KUNIT_EXPECTATION, \ left, ==, right, \ fmt, \ ##__VA_ARGS__) as opposed to our current DRYer version #define KUNIT_BASE_EQ_MSG_ASSERTION(test, \ assert_class, \ ASSERT_CLASS_INIT, \ assert_type, \ left, \ right, \ fmt, \ ...) \ KUNIT_BASE_BINARY_ASSERTION(test, \ assert_class, \ ASSERT_CLASS_INIT, \ assert_type, \ left, ==, right, \ fmt, \ ##__VA_ARGS__) #define KUNIT_BINARY_EQ_MSG_ASSERTION(test, assert_type, left, right, fmt, ...)\ KUNIT_BASE_EQ_MSG_ASSERTION(test, \ kunit_binary_assert, \ KUNIT_INIT_BINARY_ASSERT_STRUCT, \ assert_type, \ left, \ right, \ fmt, \ ##__VA_ARGS__) #define KUNIT_BINARY_EQ_ASSERTION(test, assert_type, left, right) \ KUNIT_BINARY_EQ_MSG_ASSERTION(test, \ assert_type, \ left, \ right, \ NULL) #define KUNIT_EXPECT_EQ(test, left, right) \ KUNIT_BINARY_EQ_ASSERTION(test, KUNIT_EXPECTATION, left, right) #define KUNIT_EXPECT_EQ_MSG(test, left, right, fmt, ...) \ KUNIT_BINARY_EQ_MSG_ASSERTION(test, \ KUNIT_EXPECTATION, \ left, \ right, \ fmt, \ ##__VA_ARGS__) Daniel Latypov (5): kunit: make KUNIT_EXPECT_EQ() use KUNIT_EXPECT_EQ_MSG(), etc. kunit: drop unused intermediate macros for ptr inequality checks kunit: reduce layering in string assertion macros kunit: decrease macro layering for integer asserts kunit: decrease macro layering for EQ/NE asserts include/kunit/test.h | 660 ++++++++++--------------------------------- 1 file changed, 142 insertions(+), 518 deletions(-) -- 2.34.1.703.g22d0c6ccf7-goog