[PATCH] D69585: PerformPendingInstatiations() already in the PCH

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D69585#1943222 <https://reviews.llvm.org/D69585#1943222>, @llunak wrote:

> In D69585#1942431 <https://reviews.llvm.org/D69585#1942431>, @rsmith wrote:
>
> > This needs to be done behind a flag. It's an explicit design goal that compilation behavior using a PCH or precompiled preamble behaves identically to compilation not using a PCH / precompiled preamble. The behavior of this patch is also non-conforming: we're only allowed to perform function template instantiations at their points of instantiation (essentially, at points of use + at the end of the translation unit).
>
>
> How is that different from -fmodules? Given that AFAICT this makes PCHs work the same way as modules, this should mean -fmodules also both fails the identical behaviour goal and is non-conforming.


Each header module ("header unit" in C++20 terminology) in a modules build is a distinct translation unit, so there's a point of instantiation at the end of it. It's also not a goal of `-fmodules` nor C++20 modules to produce identical output to a non-modules build; the modules language feature is intended to change the observable language semantics (unlike PCH, which is intended to improve build speed without affecting semantics).

> And to make sure I understand correctly, by behaving identically you mean that all the compiler output should be identical without even benign differences?

If by "benign differences" you mean things like different (but still correct) diagnostic output, then yes, that's the goal. I think producing the same diagnostics in a different order might be OK, though. For example, in an IDE, we can automatically precompile a header or a preamble to make interactive use more efficient, without changing the observable behavior of the compiler. We don't want a different diagnostic experience for interactive use versus standalone compilation.

In addition to the "explicit specialization after instantiation" problem you identified, attempting instantiation at the end of a preamble or PCH would also break things like this:

  template<typename T> void f();
  struct X;
  void g() { f<X>(); } // instantiation not performed yet
  
  template<typename T> void f() { T t; };
  // -- end of preamble or PCH --
  struct X {};

Here, instantiation at the end of TU is valid, but instantiation at the end of preamble / PCH would reject this valid code, because we'd instantiate `f<X>` while `X` is incomplete.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69585/new/

https://reviews.llvm.org/D69585