From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#44858: [PATCH] Make byte-compiler warn about wide docstrings Date: Thu, 26 Nov 2020 04:46:25 -0800 Message-ID: References: <87zh34wfxo.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 44858@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 26 13:53:05 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kiGll-0007BN-6K for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Nov 2020 13:53:05 +0100 Original-Received: from localhost ([::1]:44818 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kiGlk-0002Yw-6r for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 26 Nov 2020 07:53:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kiGfx-0006dN-0E for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2020 07:47:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56708) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kiGft-0006NG-Os for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2020 07:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kiGft-00039x-Ln for bug-gnu-emacs@gnu.org; Thu, 26 Nov 2020 07:47:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 26 Nov 2020 12:47:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 44858 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 44858-submit@debbugs.gnu.org id=B44858.160639479610978 (code B ref 44858); Thu, 26 Nov 2020 12:47:01 +0000 Original-Received: (at 44858) by debbugs.gnu.org; 26 Nov 2020 12:46:36 +0000 Original-Received: from localhost ([127.0.0.1]:40021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiGfT-0002qd-En for submit@debbugs.gnu.org; Thu, 26 Nov 2020 07:46:35 -0500 Original-Received: from mail-ej1-f42.google.com ([209.85.218.42]:43655) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kiGfQ-0002kb-Lp for 44858@debbugs.gnu.org; Thu, 26 Nov 2020 07:46:33 -0500 Original-Received: by mail-ej1-f42.google.com with SMTP id jx16so2148594ejb.10 for <44858@debbugs.gnu.org>; Thu, 26 Nov 2020 04:46:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=S0u/jClkJq8jpZnuJrifnaM57Jdj9yPvgNYX5RVmwpI=; b=Obt+/yGBoGjknX2whhytzG5GHJ9SKvuCD6F91Gj8R1mliJPYmX+0b4dKSlwhd0tIqe jlpMC1GDMYsTlN+wFzC1TvxFhPHQvSdyfeOUkpy/44rk8jJB5xiILRXfp9Ior+tB7Tjj vFH4rPLPNSYxTDYcz1Au/rf3AO5pWj4gDxWIBpuJIC/m7afeFtxKdMyJyWABek7AxfiC axY3ya7/HreGlrzmoGgc5vHKs7SSF3mgAlssTyLs4g6NxVanyZk5H2pW68PAKA3dxlJO tMvZI2hG8JTWm7juPuQNNDlcB1ISKFLiPrVNMEyFVM7hSRSgZnGAfTYWHh37tZKyHlaT FOBw== X-Gm-Message-State: AOAM533ME27inSP8GPriwYsqdp3n1at6OlDHMByc0tKN4pLq+Wwo3Z4K XNPZqb2dMS0/UuV7HxieQ6H20veenIniYf+jV1w= X-Google-Smtp-Source: ABdhPJy5DVHuYXtmCJaoCK9N6xK4jTNVpSR+D96Fe2R0oxoHC2tc1mnFBGosNNYVPBFESyTAP1CzTpzuHR5VWxTuTT8= X-Received: by 2002:a17:906:1918:: with SMTP id a24mr2496075eje.432.1606394786950; Thu, 26 Nov 2020 04:46:26 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 26 Nov 2020 04:46:26 -0800 In-Reply-To: <87zh34wfxo.fsf@gnus.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:194301 Archived-At: Lars Ingebrigtsen writes: > I like it. Thanks. >> I've been messing around with getting defuns to work, but I can't find a >> way for it to work reliably. The problem is that they are already macro >> expanded when we start issuing warnings, so it's not trivial to reliably >> separate defuns from other cases where lambda is used. > > I'm probably misunderstanding you completely, but do we have to separate > between lambda and defuns? lambdas can also have doc strings... Indeed they can. The problem I had was how to differentiate between the many different macros that generate lambdas. I didn't record the exact details, but it got pretty messy between `defun', `define-derived-mode', `cl-defgeneric', etc. etc. The problem I saw was basically warnings about symbols only visible after macro expansion, and that warnings would point to entirely the wrong line and column. (If anyone wants to take a look, it should be sufficient to uncomment the lambda part in my patch and run "make bootstrap".) I was looking at `byte-defop-compiler-1', but that seems to only be usable for functions and special forms? IIUC, when we compile all macros have been expanded and all information about what macro was used where is lost. But it's possible that I'm misunderstanding things, as I'm still wrapping my head around this code. >> (If you were to add defuns into the mix, we would get around 700 >> warnings for wide docstrings, several of which would be autogenerated. >> We should probably look into that at some point...) > > Yes, the autogenerated docstrings should be fixed, too -- mostly by > running them through `fill-paragraph'. I tried that in e.g. define-derived-mode, but fill.el is loaded after derived.el. So it seems like there is some fun to be had in figuring out the dependencies there...