[Tooling] [Ext] Modules and tooling: Resolving module import declarations

Gabriel Dos Reis gdr at microsoft.com
Fri Aug 31 19:09:40 CEST 2018


| -----Original Message-----
| From: Ext <ext-bounces at lists.isocpp.org> On Behalf Of Nathan Sidwell
| Sent: Friday, August 31, 2018 4:53 AM
| To: Evolution Working Group mailing list <ext at lists.isocpp.org>; WG21
| Tooling Study Group SG15 <tooling at open-std.org>
| Cc: C++ Library Evolution Working Group <lib-ext at lists.isocpp.org>
| Subject: Re: [Ext] [Tooling] Modules and tooling: Resolving module import
| declarations
| 
| On 08/31/2018 07:09 AM, Boris Kolpackov wrote:
| > Message-ID: <boris.20180831104601 at codesynthesis.com>
| >
| > Tom Honermann <tom at honermann.net> writes:
| 
| >> 2. A method of specifying a path to search for module description
| >>     files, similar to existing include paths.
| >
| > I would argue against any kind of "search paths" approach (whether for
| > modules or description files themselves). We've used them for includes
| > and I think it has proven to be brittle (I am talking about the "header
| > doesn't exist where you expect it to exist but the compiler found you
| > another one" kind of situtions) and not toolable (where shoudl I generate
| > this non-existent header?)
| 
| A search path seems the obvious choice, because of the similarity to
| include paths.  It is the route I originally went down.  It's a trap! As
| Boris says, it's brittle.  It continues the performance problems of
| searching a bunch of filesystem locations for each import.

Exactly!  Not mentioning the correctness problems.

| I abandoned that approach for an interface allowing the compiler to be
| agnostic, and other tools to plug into that.  Expect a paper for San Diego.

Great!

-- Gaby



More information about the Tooling mailing list