Bug 65834 - give error for #if with no expression at the previous location
Summary: give error for #if with no expression at the previous location
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: preprocessor (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: diagnostic
Depends on:
Blocks:
 
Reported: 2015-04-21 15:20 UTC by Manuel López-Ibáñez
Modified: 2018-09-24 01:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2017-09-28 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Manuel López-Ibáñez 2015-04-21 15:20:05 UTC
Distilled from: http://www.linuxquestions.org/questions/linux-from-scratch-13/replace-gcc-with-clang-4175491981/#post5108443

extern void foo(void);
#define TEST

int bar(void)
{
#if TEST
  foo();
#endif
  return 0;
}

Currently:

test.c:6:9: error: #if with no expression
 #if TEST
         ^

Expected something like:

test.c:6:9: error: #if with no expression
 #if TEST
     ^
test.c:2:14: note: in expansion of macro ‘TEST’

I think this could be possible by giving the error at the location of TEST (which should be the previously encoded source_location) rather that at the current one.

 #define TEST 
              ^
Comment 1 Andrew Pinski 2016-01-24 21:05:58 UTC
Maybe someone might want to put something else after TEST.  I think both are correct to warn.  clang error location might be more useful in some cases but wrong in others.  Likewise the way GCC is correct for some cases but wrong for others.  The biggest question is which happens more often in real life.  I don't have any thoughts on that one.
Comment 2 Manuel López-Ibáñez 2017-09-28 21:49:30 UTC
(In reply to Andrew Pinski from comment #1)
> Maybe someone might want to put something else after TEST.  I think both are
> correct to warn.  clang error location might be more useful in some cases
> but wrong in others.  Likewise the way GCC is correct for some cases but
> wrong for others.  The biggest question is which happens more often in real
> life.  I don't have any thoughts on that one.

Note that Clang gives the same location as GCC. My suggestion is to improve over clang to show the macro value as empty. If one adds something after TEST, then the error (and locations) would be totally different, which is ok.