On 6/6/22 6:26 PM, Daniel Ruoso via SG15 wrote:
> Actually, on a second thought, there is one thing that I think is
> still problematic.
>
> When the compiler is not replacing includes by imports, it would still
> result in different headers, which I think is going to generate a lot
> of confusion.
>
> I'd advocate for giving the compiler the tuple with the token, the
> header file and the BMI. That way it would always use the same header,
> even if not replacing the include by an import.

I agree with making this more robust.

Perhaps a slight tweak: supply the compiler with the token and BMI. if
the token contains a relative path, try to resolve it to an absolute
path via the include paths. If a match is found, then substitute the
constructed absolute path as if it had been explicitly provided. If a
match is not found, then use the BMI only when a matching token is
presented in a #include or import directive. The former rule strengthens
the #include vs import consistency while the second rule retains an
option to migrate away from include paths.

Tom.

>
> Daniel
>
> On Mon, Jun 6, 2022, 17:21 Daniel Ruoso <daniel_at_[hidden]> wrote:
>
> Great. So that matches exactly what I was advocating for.
>
> I'll try to write a paper summarizing all this, and advocating for
> that approach on all implementations.
>
> On Mon, Jun 6, 2022, 17:19 Gabriel Dos Reis <gdr_at_[hidden]> wrote:
>
> [Daniel]
> > I may have misunderstood. When the following argument is given:
> >
> > /headerUnit:angle foo.h=/some/foo.h.ifc
> >
> > Does that mean MSVC will not perform a lookup in the include
> > directories and will just apply that for both `#include
> <foo.h>` and
> > `import <foo.h>`? Even if no there was no foo.h in any of
> the include
> > directories?
>
> No, MSVC does not look up via include directories before
> applying the mapping of
> import <foo.h>;
>
> to the corresponding IFC. Additionally, if you have
> /translateInclude and
>
> #include <foo.h>;
>
> it will not look up in the include directory.
>
> However, if you specify
>
> /headerUnit /some/absolute/path/to/foo.h=/some/foo.h.ifc
>
> and you have
>
> #include <foo.h>
>
> it would first look up <foo.h> via the include directories.
> If the selected source file happens to match the mapping
> specified then it will the IFC.
>
> -- Gaby
>
> -----Original Message-----
> From: Daniel Ruoso <daniel_at_[hidden]>
> Sent: Monday, June 6, 2022 1:15 PM
> To: Gabriel Dos Reis <gdr_at_[hidden]>
> Cc: sg15_at_[hidden]; Boris Kolpackov
> <boris_at_[hidden]>
> Subject: Re: [SG15] "logical name" of importable headers
>
> Em seg., 6 de jun. de 2022 às 15:21, Gabriel Dos Reis
> <gdr_at_[hidden]> escreveu:
> > > Specifically, the input to the compiler would be a map
> from the token
> > > used after include or import to the header file and the
> bmi for that
> > > header unit.
> > I think is what MSVC does... no?
>
> I may have misunderstood. When the following argument is given:
>
> /headerUnit:angle foo.h=/some/foo.h.ifc
>
> Does that mean MSVC will not perform a lookup in the include
> directories and will just apply that for both `#include
> <foo.h>` and
> `import <foo.h>`? Even if no there was no foo.h in any of the
> include
> directories?
>
> Is there ever a situation where the compiler would need the
> path to
> the original header?
>
> daniel
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15