From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Basil L. Contovounesios" Newsgroups: gmane.emacs.devel Subject: Re: master bf21025: * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls Date: Thu, 25 Mar 2021 17:06:37 +0000 Message-ID: <87ft0j88o2.fsf@tcd.ie> References: <20210319223536.5620.7190@vcs0.savannah.gnu.org> <20210319223537.784692101A@vcs0.savannah.gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18600"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Stefan Monnier To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Mar 25 18:11:54 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lPTWT-0004jd-Ji for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 18:11:53 +0100 Original-Received: from localhost ([::1]:48140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lPTWS-0001Xi-Ir for ged-emacs-devel@m.gmane-mx.org; Thu, 25 Mar 2021 13:11:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lPTRa-0005pj-69 for emacs-devel@gnu.org; Thu, 25 Mar 2021 13:06:50 -0400 Original-Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:52098) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lPTRT-0006ka-I3 for emacs-devel@gnu.org; Thu, 25 Mar 2021 13:06:49 -0400 Original-Received: by mail-wm1-x32d.google.com with SMTP id p19so1597197wmq.1 for ; Thu, 25 Mar 2021 10:06:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tcd.ie; s=google21; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=WScGV8Q0sW7o9C3zQefSCq7WgzxlXYzUq7fmx9T0PM4=; b=M2Jj14/oGe4ilm8HZPVGvD9j4+l7sEV4ETtT3A5YcoqLedTdXWAXDEPgVBKbNdXybU PmuudermFFj86hzkinNTZiEE2QqX2L4cZ+dCfkVaDdmDF4qU/4Fd9sNr81SpJoyqe5uT Kcq015sNTG24Xg+R+IyPlm8E6ySdYHBQU6zNVmixhu7oQ3TuObb3pwadvuHlfCGtbhfH OxmcLGJxy6FaZFivcuRLAh2zAtAFO9go/MN6VoZZzLBKfO5Y9uxkiAUwwf3BecJao54q kYNQ69YLnaX5GPnBT3PziEXyvNuZ8ANGnEGUJhsmFlxkf58MhGmGixK+E6V8fgcxUb7J uY8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=WScGV8Q0sW7o9C3zQefSCq7WgzxlXYzUq7fmx9T0PM4=; b=ZdQ9aiUG9R2qvJflb9ly6GrH/lVupKQP/qdvzylZ5b91crtQzEaFS2ZNtdulurysrz XiEBawqHGZUgYk9tzgGqvjqgReEY8j9+h1CYu2ZTv6V4iDIkHMyUJbzE/4TuxZ+2/U3K ZiKKkWqWp7cMB9KrIEy+Za9Efn+144p/A1HVaHgZdIzVC1mk6QiWHxUnLaiMKZt5ehAA n/Vea2zjjsjYHyA85oSEF1nARAapWdNiX3926vOKGQ/csjkXeAT0CVPkCEDAN1KLZzFB 70JQKG0Mo39zPDYgAF4D7nd0H20p6+dymrt8rw/69jpb49ctohyjpvDq2IwikqxpESFN qGZw== X-Gm-Message-State: AOAM532m/g2OJtCkPbvUHEGRoXSuNtFR4rCeRbXmSx2W9xcBNWKWrx2W XfojRBHzlgTgGNm3GDpYb9f1Fqi2lwX0YHPb X-Google-Smtp-Source: ABdhPJyOYh3gyt6LHDk8rLui12XyddmOgtfNldVyx3WyNxjBw2sAL/osgzTJAkYCwOMz/dtGPL4rxw== X-Received: by 2002:a05:600c:35c8:: with SMTP id r8mr8812420wmq.130.1616691999829; Thu, 25 Mar 2021 10:06:39 -0700 (PDT) Original-Received: from localhost ([2a02:8084:20e2:c380:f410:82e8:3a21:eedf]) by smtp.gmail.com with ESMTPSA id z66sm7399288wmc.4.2021.03.25.10.06.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 Mar 2021 10:06:39 -0700 (PDT) In-Reply-To: <20210319223537.784692101A@vcs0.savannah.gnu.org> (Stefan Monnier's message of "Fri, 19 Mar 2021 18:35:37 -0400 (EDT)") Received-SPF: pass client-ip=2a00:1450:4864:20::32d; envelope-from=contovob@tcd.ie; helo=mail-wm1-x32d.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267040 Archived-At: --=-=-= Content-Type: text/plain monnier@iro.umontreal.ca (Stefan Monnier) writes: > branch: master > commit bf210251eadafafd1bf4176127b872030405baa3 > Author: Stefan Monnier > Commit: Stefan Monnier > > * lisp/emacs-lisp/bytecomp.el: Remember location of unresolved calls > > I've gotten tired of seeing the "function foo not known to be defined" > warning without any line number information. So this patch adds as > line number the position of the first use of that function in the file > (well, approximately, as usual). > > (byte-compile-unresolved-functions): Add POSITIONs in the alist. > (byte-compile-function-warn): Store the current position in > `byte-compile-unresolved-functions`. > (byte-compile-arglist-warn): Adjust accordingly. > (byte-compile-print-syms): Delete unused function. > (byte-compile-warn-about-unresolved-functions): Use the stored position > to give more precise warnings. Does that mean this part can be removed, or are its side effects still needed somewhere? --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=bytecomp.diff diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el index 0babbbb978..dd8d15e167 100644 --- a/lisp/emacs-lisp/bytecomp.el +++ b/lisp/emacs-lisp/bytecomp.el @@ -2190,9 +2190,6 @@ byte-compile-from-buffer (byte-compile-toplevel-file-form form))) ;; Compile pending forms at end of file. (byte-compile-flush-pending) - ;; Make warnings about unresolved functions - ;; give the end of the file as their position. - (setq byte-compile-last-position (point-max)) (byte-compile-warn-about-unresolved-functions))) byte-compile--outbuffer))) --=-=-= Content-Type: text/plain BTW, would we like the effect of declare-function to be local to its lexical scope? Would this be feasible? I guess we'd need a new var to keep track of unresolved fns per scope, and merge its remaining contents with the global unresolved and noruntime lists when popping scope, or something like that? My motivating example is, had I declared tab-bar-height within frame-notice-user-settings for --without-x builds, then that would have shadowed its later unqualified use in frame-inner-height, leaving bug#47234 unnoticed. (Of course the same would be true if the declaration were at top-level.) Remembering to support a variety of build configurations is already tricky enough, so maybe this will help prevent some subset of bugs. Or would it not be worth the effort? Thanks, -- Basil --=-=-=--