[Bug c/113631] New: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma

[Bug c/113631] New: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma

[nightstrike at gmail dot com]

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

            Bug ID: 113631
           Summary: FAIL: gcc.dg/pr7356.c, fix still fails with #pragma
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Keywords: diagnostic, testsuite-fail
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nightstrike at gmail dot com
                CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The original PR7356 highlighted a problem where a diagnostic for a problem in a
source file would point to something in an included file.  This was fixed for
the case in the PR for a subset of systems with certain standard header files. 
The original testcase was:

a
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main(int argc, char** argv)
{
  return 0;
}


The expectation is that GCC warns on the 'a', not somewhere inside stdlib.h.
This now works as indicated in that PR:

<source>:1:2: error: expected ';' before 'typedef'
    1 | a
      |  ^
      |  ;


Notably, it works differently with C++:
<source>:1:1: error: 'a' does not name a type
    1 | a
      | ^

...but at least it marks 'a' as the issue (should that be a separate PR?)

However, on mingw, we have certain constructs in our headers that still confuse
the parser, resulting in this:


In file included from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/_mingw.h:282,^M
                 from
/tmp/rt/mingw14/x86_64-w64-mingw32/include/corecrt.h:10,^M
                 from /tmp/rt/mingw14/x86_64-w64-mingw32/include/stdlib.h:9,^M
                 from /tmp/gcc/testsuite/gcc.dg/pr7356.c:4:^M
/tmp/rt/mingw14/x86_64-w64-mingw32/include/vadefs.h:14:9: error: expected '=',
',', ';', 'asm' or '__attribute__' before '#pragma'^M
 #pragma pack(push,_CRT_PACKING)^M
         ^~~~^M


It turns out that the problem is target-agnostic and is really just due to
pragmas, so I've reduced it and reproduced the problem on GNU/Linux (the pragma
is meant to be a no-op, that was a close approximation.  GCC diagnostic push
also works):


a.c:
a
#include "a.h"
int main() {}

a.h:
#pragma message "foo"

$ gcc -c a.c
a.h:1:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'#pragma'
    1 | #pragma message "foo"
      |         ^~~~~~~
a.h:1:9: note: '#pragma message: foo'

[Bug c/113631] FAIL: gcc.dg/pr7356.c, fix still fails with #pragma

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2024-01-29
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
            Version|unknown                     |14.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
<source>:1:2: error: expected ';' before 'typedef'
    1 | a

a.h:1:9: error: expected '=', ',', ';', 'asm' or '__attribute__' before
'#pragma'
    1 | #pragma message "foo"
      |         ^~~~~~~

as it's a different message it's likely using a different location to
highlight the issue.  In general it's difficult to tell whether pointing
to the first token sequence in the #included file or the last token
before the #include directive is better here.

Of course the pragma location should underline either #pragma or the whole
#pragma, not just 'message'.

Btw, same issue without the #include:

a
#pragma message "foo"

vs.

a
typedef int b;

I'm not sure it makes sense to special case the situation we've switched
files?