https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80753

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>:

https://gcc.gnu.org/g:37f373e974ac0a272b0e2b24e27c08833ad43470

commit r14-1870-g37f373e974ac0a272b0e2b24e27c08833ad43470
Author: Jakub Jelinek <ja...@redhat.com>
Date:   Thu Jun 15 14:16:17 2023 +0200

    libcpp: Diagnose #include after failed __has_include [PR80753]

    As can be seen in the testcase, we don't diagnose #include/#include_next
    of a non-existent header if __has_include/__has_include_next is done for
    that header first.
    The problem is that we normally error the first time some header is not
    found, but in the _cpp_FFK_HAS_INCLUDE case obviously don't want to
diagnose
    it, just expand it to 0.  And libcpp caches both successful includes and
    unsuccessful ones.

    The following patch fixes that by remembering that we haven't diagnosed
    error when using __has_include* on it, and diagnosing it when using the
    cache entry in normal mode the first time.

    I think _cpp_FFK_NORMAL is the only mode in which we normally diagnose
    errors, for _cpp_FFK_PRE_INCLUDE that open_file_failed isn't reached
    and for _cpp_FFK_FAKE neither.

    2023-06-15  Jakub Jelinek  <ja...@redhat.com>

            PR preprocessor/80753
    libcpp/
            * files.cc (struct _cpp_file): Add deferred_error bitfield.
            (_cpp_find_file): When finding a file in cache with deferred_error
            set in _cpp_FFK_NORMAL mode, call open_file_failed and clear the
flag.
            Set deferred_error in _cpp_FFK_HAS_INCLUDE mode if open_file_failed
            hasn't been called.
    gcc/testsuite/
            * c-c++-common/missing-header-5.c: New test.

Reply via email to