Re: #import, #pragma once to be removed in 3.4

[Geoff Keating <geoffk at geoffk dot org>]

Zack Weinberg <zack@codesourcery.com> writes:

> So we had a discussion of the problems that PCH poses for #import,
> which expanded to a discussion of the problems of #import and
> #pragma once generally, which then pretty much wound down without any
> middle ground being found between 'there must be some way to fix it'
> and 'no, sorry, there isn't'.  I think that an executive decision is
> required at this point, which falls to me as cpplib maintainer.
> 
> Accordingly: #import and #pragma once will be removed from FSF GCC in
> 3.4.  I will shortly send a patch to gcc-patches to implement that.
> 
> I have heard the concerns of the people who have problems with the
> remaining mechanism for idempotent #include, i.e. wrapper #ifndefs.
> I have a solution in mind, but I would first like to determine how
> widespread these problems are.  Please reply to this message
> (do NOT cc: gcc-announce) if you have experienced problems with
> collisions between macro names used in wrapper #ifndefs, or any other
> technical problem with this mechanism.  Please also advise if you
> could not work around the problem by editing the offending headers.

Hi Zack, 

I'm now working on a rewrite of the affected code that:

* Fully supports the Apple #import semantics even in PCH files, by
  using checksums, but with no performance impact for most compiles
  (except that building PCH files gets slightly slower).  In
  particular, builds that do not use #import will not be affected.
  I'm debating whether we want to slightly vary from the Apple
  semantics for FSF GCC to avoid even the small impact on PCH files;
  I want to measure the impact first.

* Fixes a performance issue with long include search paths, by caching
  #include names rather than stat entries and using readdir to prime the
  cache; we found that a significant amount of time on our favourite
  testcase was being taken just in hash lookups in the stat cache, most
  of which returned negative results.  It's common to have 50+ entries
  in the search path on Darwin, I think this test case had about 100 entries 
  and includes several hundred distinct files in each compile, some many
  times.

I'd ask you to hold off until I can get this work completed.  It
effectively rewrites all the header-searching logic anyway and we can
always make a decision on #import then.

While doing this, I noticed one more place in the compiler where it
cares whether two files are the same: #pragma implementation.

-- 
- Geoffrey Keating <geoffk@geoffk.org>