[all-commits] [llvm/llvm-project] c843c9: [clang] Require strict matches for defines for PCH...

[Martin Storsjö via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: c843c921a1a385bb805b2338d980436c94f83f19
      https://github.com/llvm/llvm-project/commit/c843c921a1a385bb805b2338d980436c94f83f19
  Author: Martin Storsjö <martin at martin.st>
  Date:   2022-08-10 (Wed, 10 Aug 2022)

  Changed paths:
    M clang/docs/ReleaseNotes.rst
    M clang/include/clang/Serialization/ASTReader.h
    M clang/lib/Frontend/FrontendAction.cpp
    M clang/lib/Serialization/ASTReader.cpp
    M clang/test/PCH/pch-dir.c

  Log Message:
  -----------
  [clang] Require strict matches for defines for PCH in GCC style directories

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in
b63687519610a73dd565be1fec28332211b4df5b).

When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.

The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.

The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.

This differs from GCC, which rejects PCH files if the defines differ
at all.

When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).

However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.

Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.

This fixes https://github.com/lhmouse/mcfgthread/issues/63.

Differential Revision: https://reviews.llvm.org/D126676