Message ID | 20240419150427.897379-1-tromey@adacore.com |
---|---|
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CF6413849AD9 for <patchwork@sourceware.org>; Fri, 19 Apr 2024 15:05:36 +0000 (GMT) X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by sourceware.org (Postfix) with ESMTPS id 8F210384AB7E for <gdb-patches@sourceware.org>; Fri, 19 Apr 2024 15:04:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 8F210384AB7E Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=adacore.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 8F210384AB7E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::d34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713539092; cv=none; b=r8K0lQUBvA7CFOYi2Lil75y3p2KWTw6xbwxCj4RvEF4E/rT4FLKxQTNq0XkDnDjcqy4npAC86OK9zo7Cv95Jz8r8oFqGMVnfwU2nT6OHO5rSHFzpR9MfvcWI3nVbCmzeQs2mHpxwzcsj65rTf89UkUWR7Ne8CXmY6S+TyDNTfwo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1713539092; c=relaxed/simple; bh=wjSTja//gbfy31lKhVqvrN/cB33HdVInSeQqCgti7vY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=pTjuhKrJ+2fj8nOQemyU8YvoVlE1MJLmKnJwpOYTgqIFi3cODMGR8jXl/X4w7o+W5rBEl0CZUGnVUYLuZR6jkMQFCVKXd76C8vzUB4a037dIm1E9/9fQuPwnCx/g5INCri8uXZhkROOtFYmFWDrJmh8LAQtmZ/VZezTGSJOhVzU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-io1-xd34.google.com with SMTP id ca18e2360f4ac-7d9e2a5e097so70311939f.3 for <gdb-patches@sourceware.org>; Fri, 19 Apr 2024 08:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=adacore.com; s=google; t=1713539084; x=1714143884; darn=sourceware.org; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=wjSTja//gbfy31lKhVqvrN/cB33HdVInSeQqCgti7vY=; b=TGO2rAeSGrbT9Kew+GklAv1DPbZyNGNJgdclPS+I75Wn0T08ldZtFVpjkfLEDfmlDF 1tHJZtk1TWvzrbTj5Jj4JRX9qp94NrPSphXnT8KIVPbe2/+RTb7AzSZHJLgigEFtQqjr MHhvmJ4otQCwd3lvalfqIO5pxajGk/rJv8kOpkHaRJfPxQU1ibDdJb0EsshNrPGOtVn1 g0muzHrDh+jDxxdmSX7QVyKgjA1BF9Gd1O3Yhr4ofiWV7c6xFtC1fUCmjFZvlLFvaQGA DTRdghPWBsew+9cxd/L7ufY3scU6Y/Q6Tb/prrkShZyI2Ez8uF+uBYaenwQUoUI4A8lX CxKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713539084; x=1714143884; h=content-transfer-encoding:mime-version:message-id:date:subject:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wjSTja//gbfy31lKhVqvrN/cB33HdVInSeQqCgti7vY=; b=p64oNENR4PLdN50X1u4hIZL5S4pAWD6mUmDn+ifueZT4bhBgRU+4sqR5oPf6UnKrHC dImqrCCtVDhqdu840PtJlwdcvRp7p3TUNVruOZ66ESdqqHWXnlITSnS+mkRqNs7yPSUO wMmh92OjlsBbN6sNrBIHhttTilnaWJHMkEDZrq+SfnDq32j81+tidBji9i0CIXyoRdLH 3etifHWhq64gybB0Ub88FLdvnDdzyRM5OdYPsev6EF42hnxo9UdphqnM4EA++VjKmxw2 Z+3MTTwkWHDhQLivw+PFtcV21Vj55CJTOwPe4kZjftOGt19B6qlajbht9EB9wqa7FNQg V7AQ== X-Gm-Message-State: AOJu0YyejeDN+XYlYFudhod5+D5Rqh51lPloM1vAy+tPBxaW0t7vTtwk avBtb/QQkpBqDDTDQDnvS5TIAb/xeyn6sQ9ExQXhduczlnPfDhdJAIuv7yKLqWva+p7tcaJC5Bg = X-Google-Smtp-Source: AGHT+IGUNSSGt9ppq1/g1fU53t2FlshVmvxwEA3lNpkfQIfaESgczO4VrpvKguXBGEyRNyvI8ZRKRw== X-Received: by 2002:a5e:870b:0:b0:7da:1885:b713 with SMTP id y11-20020a5e870b000000b007da1885b713mr2931222ioj.2.1713539083404; Fri, 19 Apr 2024 08:04:43 -0700 (PDT) Received: from localhost.localdomain (97-122-86-252.hlrn.qwest.net. [97.122.86.252]) by smtp.gmail.com with ESMTPSA id o1-20020a056638124100b0048464427351sm1086506jas.78.2024.04.19.08.04.42 for <gdb-patches@sourceware.org> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Apr 2024 08:04:42 -0700 (PDT) From: Tom Tromey <tromey@adacore.com> To: gdb-patches@sourceware.org Subject: [PATCH v4 0/4] Add include guard checker and reformatter Date: Fri, 19 Apr 2024 09:03:38 -0600 Message-ID: <20240419150427.897379-1-tromey@adacore.com> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org |
Series |
Add include guard checker and reformatter
|
|
Message
Tom Tromey
April 19, 2024, 3:03 p.m. UTC
Here's v4 of the include guard checker / reformatter. It's really just v2, but this time not sent using b4, which was sending the wrong patches. Tom
Comments
On 2024-04-19 11:03, Tom Tromey wrote: > Here's v4 of the include guard checker / reformatter. > > It's really just v2, but this time not sent using b4, which was > sending the wrong patches. > > Tom > So, after patch 4/4, your script doesn't need to handle the the `defined(FOO_H)` style (OLDDEF in your script). I think you could remove support for that, it would simplify it a little bit. Either way: Approved-By: Simon Marchi <simon.marchi@efficios.com> Simon
On 2024-04-19 16:26, Simon Marchi wrote: > So, after patch 4/4, your script doesn't need to handle the the > `defined(FOO_H)` style (OLDDEF in your script). I think you could > remove support for that, it would simplify it a little bit. Doesn't it need to handle it in case someone creates a new header and writes defined(FOO_H) manually? You'd still want the hook to fix that.
On 2024-04-19 12:55, Pedro Alves wrote: > On 2024-04-19 16:26, Simon Marchi wrote: >> So, after patch 4/4, your script doesn't need to handle the the >> `defined(FOO_H)` style (OLDDEF in your script). I think you could >> remove support for that, it would simplify it a little bit. > > Doesn't it need to handle it in case someone creates a new header and writes > defined(FOO_H) manually? You'd still want the hook to fix that. > IMO, after the initial run, the script doesn't really need to auto fix things, it can just check and report errors. Simon
>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes: Simon> On 2024-04-19 12:55, Pedro Alves wrote: >> On 2024-04-19 16:26, Simon Marchi wrote: >>> So, after patch 4/4, your script doesn't need to handle the the >>> `defined(FOO_H)` style (OLDDEF in your script). I think you could >>> remove support for that, it would simplify it a little bit. >> >> Doesn't it need to handle it in case someone creates a new header and writes >> defined(FOO_H) manually? You'd still want the hook to fix that. >> Simon> IMO, after the initial run, the script doesn't really need to auto fix Simon> things, it can just check and report errors. I had it work that way initially, but it was irritating to know that the script could do this for me without my intervention, since it had already figured out exactly what to do. Tom
On 2024-04-19 19:43, Simon Marchi wrote: > On 2024-04-19 12:55, Pedro Alves wrote: >> On 2024-04-19 16:26, Simon Marchi wrote: >>> So, after patch 4/4, your script doesn't need to handle the the >>> `defined(FOO_H)` style (OLDDEF in your script). I think you could >>> remove support for that, it would simplify it a little bit. >> >> Doesn't it need to handle it in case someone creates a new header and writes >> defined(FOO_H) manually? You'd still want the hook to fix that. >> > > IMO, after the initial run, the script doesn't really need to auto fix > things, it can just check and report errors. The Black pre-hook fixes things for you instead of reporting formatting issues. I don't see why should this hook be held to different standards?