From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: native-comp-async-report-warnings-errors default value Date: Sat, 8 Jan 2022 04:29:42 +0200 Message-ID: References: <87h7dj7su7.fsf@gmail.com> <83r1cnlu6y.fsf@gnu.org> <87czo77rx7.fsf@gmail.com> <837dcmamt2.fsf@gnu.org> <83v90694ka.fsf@gnu.org> <83v901zdh6.fsf@gnu.org> <83k0g3cagl.fsf@gnu.org> <8ea45edf-0bd2-a9b4-2341-e08446ea9965@yandex.ru> <9325beca-d34f-23f8-17a1-c52863b2ae82@yandex.ru> <5c75fd47-5e50-938d-6f4d-1882ac8cbdb1@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26388"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 Cc: Eli Zaretskii , emacs-devel@gnu.org, Stefan Kangas , rpluim@gmail.com To: Andrea Corallo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jan 08 03:32:03 2022 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 1n61WV-0006bb-EH for ged-emacs-devel@m.gmane-mx.org; Sat, 08 Jan 2022 03:32:03 +0100 Original-Received: from localhost ([::1]:40592 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n61WT-0003Sb-Jc for ged-emacs-devel@m.gmane-mx.org; Fri, 07 Jan 2022 21:32:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56978) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n61Vi-0002mI-IY for emacs-devel@gnu.org; Fri, 07 Jan 2022 21:31:14 -0500 Original-Received: from [2a00:1450:4864:20::331] (port=55115 helo=mail-wm1-x331.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n61Vg-0005Sw-Nb; Fri, 07 Jan 2022 21:31:14 -0500 Original-Received: by mail-wm1-x331.google.com with SMTP id o30so5094195wms.4; Fri, 07 Jan 2022 18:31:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tl9FQngUV/SlZhzhSk6aH02rXdHA/xZ7RiwnbShqRBU=; b=NbGsu7Fm9RRLMKXsg/7SE1+CufOicQQIBm0Zwar5wOEmqB90OBS5LEF3i/lPNe0O4I wcisrPsbdOWEjzlHbh+lkdeP4rQkIBeeq7FLuMiUQGqOOmxUGdT8v+b2KVTY8HKFijP2 sjY516A5YCKlSw3qY5CJskiYoLAOGVDIX/CzvGNoaLtrPcatFpSwxpGYaZDtHHYjAyG2 fSjgJEVGAW3gysqfnVl7Hz3P+LdKiTqY46+yLyDpIW1kdgCMcSNOxlSvOZIPwLxINFyy jNnjjup6Lkmo09J46qh/boeooN0EGLvh4CXhcr5WLGXa1wtmuQjknqj6yQNcfqPapJDF fEjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=tl9FQngUV/SlZhzhSk6aH02rXdHA/xZ7RiwnbShqRBU=; b=tQrMZ4URvh+uAp+4K1U8FiEqY/3o4zBQ405tYrpT5cZY+ZfV8ezzLcaPzLL+8fMjpm E6+HnGrsz+onbtVg4BMdJ/P02YKrpQN5WOsMI9Ds0b9ZALS4aKerJyrMOxDN/bUtljBk rU39HTEr0VSFfaWNacMuT9KnaubO/8Jr2o/KQiGyBFS5+M6JDSDH5HJhNSrPSNpGEjgq 3Uqqnqv8N8eJvba2vrq7NQKUH1G8TOQSWi6x5ky7/BBqqVOxgZRMAixiIIijaaYm+fI0 KSPtmPesWpN7s+wKkQez8QjmXbPp+4OM7nnXTPWELaER6zZVYpM0J2vIZLZ+1qi+hNsn n+vA== X-Gm-Message-State: AOAM530JBZ11zAPgVv51QZ4Dx/i6aZIdPyAvrxuqjy7O7qnxvIiydPrB lhtm9N3VmVX+3EbBtOuvWIBnVHTYtzQ= X-Google-Smtp-Source: ABdhPJzAqf+uFlvv0W6J40ybm+Z0Epe4nz5q7DdQC/8baVnjZQTZw64+J/I5+0S1e6zGfy6EvKuS+g== X-Received: by 2002:a05:600c:1c18:: with SMTP id j24mr13217472wms.189.1641609069927; Fri, 07 Jan 2022 18:31:09 -0800 (PST) Original-Received: from [10.108.248.131] ([185.209.196.168]) by smtp.googlemail.com with ESMTPSA id e20sm350827wme.25.2022.01.07.18.31.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Jan 2022 18:31:09 -0800 (PST) In-Reply-To: Content-Language: en-US X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a00:1450:4864:20::331 (failed) Received-SPF: pass client-ip=2a00:1450:4864:20::331; envelope-from=raaahh@gmail.com; helo=mail-wm1-x331.google.com X-Spam_score_int: -33 X-Spam_score: -3.4 X-Spam_bar: --- X-Spam_report: (-3.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-2.691, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, 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.29 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:284438 Archived-At: On 30.12.2021 11:37, Andrea Corallo wrote: > Indeed it has effect in the runtime. But as you say this is because the > byte compiler generates different code for that (in this case a top > level form). In the case of the native compiler we'd need to store and > reuse a bunch of information for following native compilation that has > to happen after. Store in .elc files, I take it. >> But... >> >>> As the bytecompiler pipeline was always assumed to be the only and last >>> compilation step, bytecode is ATM not designed to retain these >>> information. I'm sure it's extensible somehow but we probably need some >>> advise on what's the best way to approach this. >> >> ...I suppose you might want to access that information without >> evaluating said additional byte code forms either. >> >> Or could it evaluate them anyway? If native compilation happens after >> the code is loaded, the symbols will have the necessary properties >> then. > > Maybe a sufficient solution is an ad hoc local variable emitted (when > necessary) in the .elc file with like an a-list function -> declaration > specifiers we are interested in? I was even going to suggest that you would parse those (byte-code ...) forms in compiled files -- as long as they actually vary very little, it could be handled by a small interpreter. But maybe we could keep those forms uncompiled without a significant performance downside? Someone could benchmark that. Then the .elc files would just contain (function-put ...) on top-level instead. Or if you really need the declarations available before the corresponding functions are defined (I don't know if you compile every encountered function right away, or wait until the whole file is parsed), the order of forms in .elc files could be swapped: first property declaration, then definition.