On Fri, Sep 27, 2024 at 09:54:13AM -0400, Lewis Hyatt wrote:
> A couple comments that may be helpful...
>
> -This is also PR 64117 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117)
>
> -I submitted a patch last year for that but did not get any response
> (https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635648.html).
Oops, sorry, wasn't aware of that.
Note, I've already committed it.
> I guess I never pinged it because I am still trying to ping two other
> ones :). My patch did not switch to vec so it was not as nice as this
> one. I wonder though, if some of the testcases I added could be
> incorporated? In particular the testcase from my patch
Maybe.
> pragma-diagnostic-3.C I believe will still be failing after this one.
> There is an issue with C++ because it processes the pragmas twice,
> once in early mode and once in normal mode, that makes it do the wrong
> thing for this case:
>
> t.h:
> ----
> #pragma GCC diagnostic push
> #pragma GCC diagnostic ignored...
> //no pop at end of the file
>
> t.c
> ----
> #include "t.h"
> #pragma GCC diagnostic pop
> //expect to be at the initial state here, but won't be if t.h is a PCH
>
> In my patch I had separated the PCH restore from a more general "state
> restore" logic so that the C++ frontend can restore the state after
> the first pass through the data.
People shouldn't be doing this, without PCH or with it, and especially not
with PCH, that is simply too ugly.
That said, this was the reason why I have saved also the m_push_list
vector and not just the history. If that isn't enough and there is some
other state on the libcpp side, I'd think we should go with a sorry and tell
the user not to do this with PCH. It becomes a nightmare already if e.g.
the command line -Werror=something -Wno-error=somethingelse overrides
differ between the PCH creation and PCH reading (my first version of
the patch saved m_classify_diagnostic array but that broke tests relying
on those differences).
Jakub
