220 41243 article Path: news.gmane.org!.POSTED!not-for-mail From: masse.nicolas@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Modules and preambule, just why? Date: Tue, 11 Dec 2018 14:12:30 -0800 (PST) Lines: 223 Approved: news@gmane.org Message-ID: References: <16989401-2f0d-4200-997e-0ac60b47bec3@isocpp.org> <08290107-c63b-3ef6-09d4-16c7b6c495ab@honermann.net> <0727d34e-0bad-3689-e315-2136bb359e65@honermann.net> <41ef0549-4ff9-4d0d-b033-5eb30055490c@isocpp.org> <36e9388e-9b8d-4c93-9a0a-bedfb00c135f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_83_2141504049.1544566350748" X-Trace: blaine.gmane.org 1544566227 9210 195.159.176.226 (11 Dec 2018 22:10:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 22:10:27 +0000 (UTC) Cc: victor.dyachenko@gmail.com, ville.voutilainen@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCCJBHV4UALBBT7MYDQAKGQEUBEPV5Y@isocpp.org Tue Dec 11 23:10:23 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWqEQ-0002I0-D4 for gclcip-std-proposals@m.gmane.org; Tue, 11 Dec 2018 23:10:22 +0100 Original-Received: by mail-yw1-f72.google.com with SMTP id d78sf9729948ywa.19 for ; Tue, 11 Dec 2018 14:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=WlHcjgMEiKvbcotso1H+6/pZrZxLM2g14WXn4LbeUKE=; b=SexbhP9fx9DmUwuTcGUtRZZH9xIG4WQUX2SNo4YdU/rwgKyVGzDZKQ1BbQxI+70PNR b59+9PcRMp9BucwxB7jb7FEj/KJ0sEVklAWkjmMnlMwTelUr8W/uYX2qEjZq245vuyeJ DfmIRrJ2QJdOTp94eQbbXJ6KFSTbEKy8PZmO2iVPXxp0/gO7ME8kQcPMB4qYRa8ca/Ba jiXy6Uwa+umWDmPfLdWwZ09ePNszEhxciKeRyDdJr4L4x/BLMdH8C8hxwFI9jo6ch6RC re4/wKhiV/4XYEfcFWoC6Dx0wIzHvMBWPeTUHp5wQtPTYuKs4m6LnNJl42BTmRqC4Two lk4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=WlHcjgMEiKvbcotso1H+6/pZrZxLM2g14WXn4LbeUKE=; b=QC2YzpoE2ae6Z/XahnzpV+vFioGEEp7tI2xUdrUF0yxkMom10XSY9QH7Z9Y3nRKN5H 7y8AUr2RwotBhn7ymdPhflF8tCZ29AICC4s+CBGgsf1Wx2Ly+ut856MW749SGxluw6HR gLglxJY1LMN9uuQB8hJGUI/R8MzY7ZdMV/Va1PZrKNzuIQtG0XH2fn4HQkt/Ty7035oA 0lmp4U9ezoSzdSMFSr5Pb0L14GSPEvHqE+T7fv4dCPtxTLHLbM8su7YcjVsA3Inwe9Ix jcF0jMfv2fIdAJ9ZQslzgjb+My1GmQSK14NHANtv7fhpnuUgKqW26bCwVNZMbesL/xOQ 78Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=WlHcjgMEiKvbcotso1H+6/pZrZxLM2g14WXn4LbeUKE=; b=g/coUwRfY+Dbq2OR0DDc3y8eKDkdtqPoCvGdrWdKY0FmY5/WgOABNBPNZffr2FblRT GxN/efL0mosP4BB5PIpKAU13diWEFPHPCQZiA1cdRiTKo1cxQtey8qsgnUTzKEBeZF+J dgiUSC8fjehbRRHLKz6glf/9/PPQYViftWcnUaDoYvdg1QbYXTWXOjHkLfwywSb6a1on lqxpbcI55aqQpvulbPC5xPrneXNJ1vvWimZ1uE6ysoRhRGYxrOFbN5GukNzgijh8lb6r ghuIi/zL9TeX1v3bwmR6j7ClCuRLHb5BMYCK8ek+FPwJ/GfBlke84qB+0ut+3cNQS3b1 cZ5Q== X-Gm-Message-State: AA+aEWYbJnBD/WSuCMDD1Zu22N481CIPf01dkUEffE2cH5KN0NyyrwBK VT3EGO5zPWQmWXNR11+BTHW/Pw== X-Google-Smtp-Source: AFSGD/XRi0QlIgNg11kIXBgorFxKcjA4aVx8SWEB3rqvaIfsL42A9/Y965rhKFpSDHLo6zhz4arb4w== X-Received: by 2002:a25:2590:: with SMTP id l138mr8201253ybl.87.1544566352849; Tue, 11 Dec 2018 14:12:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3515:: with SMTP id c21ls8304402ywa.8.gmail; Tue, 11 Dec 2018 14:12:31 -0800 (PST) X-Received: by 2002:a81:7a02:: with SMTP id v2mr292407ywc.3.1544566351322; Tue, 11 Dec 2018 14:12:31 -0800 (PST) In-Reply-To: X-Original-Sender: Masse.Nicolas@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41243 Archived-At: ------=_Part_83_2141504049.1544566350748 Content-Type: multipart/alternative; boundary="----=_Part_84_1647047048.1544566350749" ------=_Part_84_1647047048.1544566350749 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I see no problem with the binary format of the module files being=20 implementation defined.=20 Just my 2 cents :) . Le vendredi 7 d=C3=A9cembre 2018 16:48:42 UTC+1, Tom Honermann a =C3=A9crit= : > > On 12/7/18 12:57 AM, Victor Dyachenko wrote:=20 > > IIRC initially modules were based on some sort of high-level C++ AST=20 > > representation - XPR=20 > > (https://parasol.tamu.edu/pivot/publications/user-guide.pdf). I'm=20 > > talking about Gaby's/VC++ implementation. Do they use different=20 > > approach now?=20 > > My understanding is that Microsoft is (still) using an internal fork of= =20 > IPR (https://github.com/GabrielDosReis/ipr).=20 > > > A there any people here aware of gcc/clang approach?=20 > > Clang uses its own AST serialization format. It is the same format=20 > Clang uses for pre-compiled headers, .ast files, and traditional Clang=20 > modules. These files are Clang specific and not historically compatible= =20 > across Clang versions.=20 > > Gcc is also using its own AST serialization format that reflects gcc's=20 > internal AST. Nathan Sidwell discusses this in some of his talks. You= =20 > might want to watch his talk from this year's GNU Tools Cauldron=20 > (https://www.youtube.com/watch?v=3D5CadIjPRZpM). He talks about AST=20 > serialization around the 20 minute mark.=20 > > > And if XPR is enough to represent modules interface files (is it?),=20 > > can't it be standardized at least in theory?=20 > > IPR has limitations. For example, it does not store full source=20 > information nor preprocessor information (no column or macro expansion=20 > information). This means consumers can't accurately map imported=20 > constructs back to source code (for example, in diagnostics).=20 > > In practice, I don't think something can be standardized here, nor do I= =20 > think it would be beneficial. There are competing requirements for how= =20 > much data to store (different compilers/tools need different=20 > information). A goal of modules is to improve compile times and a=20 > common format would impose overhead relative to what can be accomplished= =20 > with a highly optimized compiler/tool specific format. Harder questions= =20 > involve implementation defined things. How would compiler intrinsics=20 > and language extensions be handled? How would implementation defined=20 > behavior in general be handled? (The standard has many cases where=20 > implementation defined behavior can impact the AST). The committee has= =20 > discussed this a number of times and my impression is that there is no=20 > consensus for a standard format (though the committee has not actually=20 > polled this).=20 > > I think a more interesting question is, what would a standard format=20 > enable you to do that you wouldn't be able to otherwise? Can we enable=20 > those goals in another way? For example, would implementation specific= =20 > tools (potentially defacto industry standards like c++filt) that expose= =20 > information from module artifacts, potentially in some standard format,= =20 > be helpful?=20 > > Tom.=20 > > --=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/cc398899-8356-4d7a-a0ae-29fa5cfa17c1%40isocpp.or= g. ------=_Part_84_1647047048.1544566350749 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see no problem with the binary format of the module= files being implementation defined.
Just my 2 cents :) .

Le vendredi 7 d=C3=A9cembre 2018 16:48:42 UTC+1, Tom Honermann a= =C3=A9crit=C2=A0:
On 12/7/18 1= 2:57 AM, Victor Dyachenko wrote:
> IIRC initially modules were based on some sort of high-level C++ A= ST=20
> representation - XPR=20
> (https://parasol.tamu.edu/pivot/public= ations/user-guide.pdf). I'm=20
> talking about Gaby's/VC++ implementation. Do they use differen= t=20
> approach now?

My understanding is that Microsoft is (still) using an internal fork of= =20
IPR (https://github.com/GabrielDosR= eis/ipr).

> A there any people here aware of gcc/clang approach?

Clang uses its own AST serialization format.=C2=A0 It is the same forma= t=20
Clang uses for pre-compiled headers, .ast files, and traditional Clang= =20
modules.=C2=A0 These files are Clang specific and not historically comp= atible=20
across Clang versions.

Gcc is also using its own AST serialization format that reflects gcc= 9;s=20
internal AST.=C2=A0 Nathan Sidwell discusses this in some of his talks.= =C2=A0 You=20
might want to watch his talk from this year's GNU Tools Cauldron=20
(https://ww= w.youtube.com/watch?v=3D5CadIjPRZpM).=C2=A0 He talks about AST=20
serialization around the 20 minute mark.

> And if XPR is enough to represent modules interface files (is it?)= ,=20
> can't it be standardized at least in theory?

IPR has limitations.=C2=A0 For example, it does not store full source= =20
information nor preprocessor information (no column or macro expansion= =20
information).=C2=A0 This means consumers can't accurately map impor= ted=20
constructs back to source code (for example, in diagnostics).

In practice, I don't think something can be standardized here, nor = do I=20
think it would be beneficial.=C2=A0 There are competing requirements fo= r how=20
much data to store (different compilers/tools need different=20
information).=C2=A0 A goal of modules is to improve compile times and a= =20
common format would impose overhead relative to what can be accomplishe= d=20
with a highly optimized compiler/tool specific format.=C2=A0 Harder que= stions=20
involve implementation defined things.=C2=A0 How would compiler intrins= ics=20
and language extensions be handled?=C2=A0 How would implementation defi= ned=20
behavior in general be handled?=C2=A0 (The standard has many cases wher= e=20
implementation defined behavior can impact the AST).=C2=A0 The committe= e has=20
discussed this a number of times and my impression is that there is no= =20
consensus for a standard format (though the committee has not actually= =20
polled this).

I think a more interesting question is, what would a standard format=20
enable you to do that you wouldn't be able to otherwise? Can we ena= ble=20
those goals in another way?=C2=A0 For example, would implementation spe= cific=20
tools (potentially defacto industry standards like c++filt) that expose= =20
information from module artifacts, potentially in some standard format,= =20
be helpful?

Tom.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/cc398899-8356-4d7a-a0ae-29fa5cfa17c1= %40isocpp.org.
------=_Part_84_1647047048.1544566350749-- ------=_Part_83_2141504049.1544566350748-- .