Re: r207814 - -fsyntax-only for a test

2014-05-02 Thread Lubos Lunak
On Friday 02 of May 2014, Nick Lewycky wrote:
 On 1 May 2014 17:12, Nick Lewycky nlewy...@google.com wrote:
  On 1 May 2014 16:58, Lubos Lunak l.lu...@centrum.cz wrote:
  Author: llunak
  Date: Thu May  1 18:58:20 2014
  New Revision: 207814
 
  URL: http://llvm.org/viewvc/llvm-project?rev=207814view=rev
  Log:
  -fsyntax-only for a test
...
   // RUN: %clang_cc1 -E -frewrite-includes %s -I%S/Inputs/ | %clang_cc1
  -Wall -fsyntax-only -Wunused-macros -x c - 21  %t.1
  -// RUN: %clang_cc1 -I%S/Inputs/ -Wall -Wunused-macros %s 21  %t.2
  +// RUN: %clang_cc1 -I%S/Inputs/ -Wall -Wunused-macros -fsyntax-only %s
  21  %t.2
 
  Huh? This test is running clang -cc1 which defaults to only syntax
  checking unless something else is specified. -fsyntax-only isn't a -cc1
  flag, it's a clang flag.
 
  Please revert.

 Heh, I just saw the discussion on r207808. I understand what happened.

 %clang has its own set of flags and reads them, then fork+exec's %clang_cc1
 with a different set of flags. The suggestion of using -fsyntax-only and
 updating to %clang_cc1 were mutually incompatible, just using %clang_cc1
 was the right thing here.

 Well, there are about 2670 tests that use %clang_cc1 -fsyntax-only (including 
the first call of this very test even before I added the flag to the second 
call), so apparently it is not mutually incompatible. So if it is not 
supposed to be there, you rather want the right grep+sed and I don't feel 
like doing that for 2670 tests, given that I had no idea about this.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Allow overriding -split-dwarf-file

2014-05-02 Thread Lubos Lunak
On Friday 11 of April 2014, Eric Christopher wrote:
 On Fri, Apr 4, 2014 at 9:07 AM, Lubos Lunak l.lu...@centrum.cz wrote:
  On Friday 04 of April 2014, David Blaikie wrote:
  Oops, re-add cfe-commits.
 
  On Fri, Apr 4, 2014 at 8:34 AM, David Blaikie dblai...@gmail.com wrote:
   On Fri, Apr 4, 2014 at 8:24 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   changing DW_AT_GNU_dwo_name explicitly after the build, but that
   seems needlessly complex given that this seems to be exactly what the
   option does. I don't see why I would be allowed to override any
   option except for this one.
  
   -Xclang and the underlying driver arguments aren't really a
   stable/guaranteed interface. I'd be more inclined to accept this
   change if it were just for some debugging, but since it sounds like
   you want to rely on it, it's good for us to understand the goal and
   perhaps suggest or provide the best way of achieving it long-term.
 
   It's stable/guaranteed enough for me, and I'd rather have a clean
  solution that maybe breaks one day than something hackish the whole time.

 I'm guessing you mean that the actual output file name differs? I.e.
 some sort of temporary cached file ala ccache that doesn't have the
 same name as the file that you've just compiled?

 Yes. Something like

 clang -c -g -gsplit-dwarf a.cpp

 may end up actually becoming something along the lines of

 clang -c -x c - -g -gsplit-dwarf -o /tmp/fhqtewdsg.o

 The directory ends up 
 being the same here (or can be set with, as you surmised
 -fdebug-compilation-dir).

 If so, I don't mind an option to set here necessarily, but would like
 to see it plumbed through and not rely on Xclang options.

 Like this?

-- 
 Lubos Lunak
From 5f6da37c00e66931dc3867d9b5c8af30c803e12a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 4 Apr 2014 09:12:59 +0200
Subject: [PATCH] -fdebug-compilation-dir and -fsplit-dwarf-file also in the
 driver

This allows overriding the normal values in special cases as such
distributed build systems performing the compilation in a chroot
where the expected locations do not exist.
---
 include/clang/Driver/CC1Options.td  |  4 
 include/clang/Driver/Options.td |  6 ++
 lib/Driver/Tools.cpp| 32 
 lib/Frontend/CompilerInvocation.cpp |  2 +-
 test/CodeGen/split-debug-filename.c |  7 +--
 test/Driver/debug.c |  4 
 test/Driver/split-debug.c   |  8 +++-
 7 files changed, 43 insertions(+), 20 deletions(-)

diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index e84a20b..3f85c00 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -128,8 +128,6 @@ def disable_llvm_verifier : Flag[-], disable-llvm-verifier,
   HelpTextDon't run the LLVM IR verifier pass;
 def disable_red_zone : Flag[-], disable-red-zone,
   HelpTextDo not emit code that uses the red zone.;
-def fdebug_compilation_dir : Separate[-], fdebug-compilation-dir,
-  HelpTextThe compilation directory to embed in the debug info.;
 def dwarf_debug_flags : Separate[-], dwarf-debug-flags,
   HelpTextThe string to embed in the Dwarf debug flags record.;
 def dwarf_column_info : Flag[-], dwarf-column-info,
@@ -405,8 +403,6 @@ def fsjlj_exceptions : Flag[-], fsjlj-exceptions,
   HelpTextUse SjLj style exceptions;
 def main_file_name : Separate[-], main-file-name,
   HelpTextMain file name to use for debug info;
-def split_dwarf_file : Separate[-], split-dwarf-file,
-  HelpTextFile name to use for split dwarf debug info output;
 def fno_wchar : Flag[-], fno-wchar,
   HelpTextDisable C++ builtin type wchar_t;
 def fconstant_string_class : Separate[-], fconstant-string-class,
diff --git a/include/clang/Driver/Options.td b/include/clang/Driver/Options.td
index 8d2e368..1477f3d 100644
--- a/include/clang/Driver/Options.td
+++ b/include/clang/Driver/Options.td
@@ -910,6 +910,12 @@ def fdebug_types_section: Flag [-], fdebug-types-section, Groupf_Group,
   Flags[CC1Option], HelpTextPlace debug types in their own section (ELF Only);
 def fno_debug_types_section: Flag[-], fno-debug-types-section, Groupf_Group,
   Flags[CC1Option];
+def fsplit_dwarf_file : Separate[-], fsplit-dwarf-file, Groupf_Group,
+  Flags[CC1Option],
+  HelpTextFile name to use for split dwarf debug info;
+def fdebug_compilation_dir : Separate[-], fdebug-compilation-dir, Groupf_Group,
+  Flags[CC1Option],
+  HelpTextThe compilation directory to embed in the debug info.;
 def g_Flag : Flag[-], g, Groupg_Group,
   HelpTextGenerate source level debug information, Flags[CC1Option];
 def gline_tables_only : Flag[-], gline-tables-only, Groupg_Group,
diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp
index 94d13b2..2267d15 100644
--- a/lib/Driver/Tools.cpp
+++ b/lib/Driver/Tools.cpp
@@ -2087,6 +2087,11 @@ static bool shouldUseLeafFramePointer(const ArgList Args,
 
 /// Add a CC1 option to specify the debug

Re: [PATCH] Handle properly somewhat special cases of -main-file-name

2014-05-02 Thread Lubos Lunak
On Friday 11 of April 2014, Eric Christopher wrote:
 There's no guarantee that the option will continue to exist at all so
 I'd really prefer that you not use it. Any time you have to use
 -Xclang to set something then it's not an exposed option that you
 should be using.

 That said, if we can come up with a structured set of uses for this
 sort of compilation strategy rather than piecemeal then we should
 discuss it and how it'll fit into the driver.

 So how about this patch?

 As said elsewhere, something like

 cd /output ; clang -c -g -gsplit-dwarf /source/a.cpp

 may need to be turned by a distributed build system into something like

 cd / ; clang -c -x c - -g -gsplit-dwarf -o /tmp/fhqtewdsg.o

 These options allow getting the same .o as with the first command by adding

 -fmain-file-name /source/a.cpp -fdebug-compilation-dir /output 
-fsplit-dwarf-file /output/a.dwo

  On Fri, Apr 4, 2014 at 5:02 AM, Lubos Lunak l.lu...@centrum.cz wrote:
The handling of -main-file-name in CGDebugInfo::CreateCompileUnit()
   can result in incorrect DW_AT_name in somewhat special cases:
  
   1)
   $ touch /tmp/a.cpp
   $
   clang++ -Wall -c /tmp/a.cpp -g -o /tmp/a.o -Xclang -main-file-name
   -Xclang /new/path/a.cpp $ readelf -wi /tmp/a.o | grep DW_AT_name
   12   DW_AT_name: (indirect string, offset:
   0x15): /tmp/new/path/a.cpp
  
   2)
   $ touch /tmp/a.cpp
   $ cd /
   $ cat /tmp/a.cpp | clang++ -Wall -x
   c++ -c - -g -o /tmp/a.o -Xclang -main-file-name -Xclang a.cpp
   $ readelf -wi /tmp/a.o | grep DW_AT_name
   12   DW_AT_name: (indirect string, offset: 0x15): /a.cpp
  
The attached patch fixes those. Ok to commit?

-- 
 Lubos Lunak
From 3344ee849a65b05b3506809bf794e08f4783f575 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 4 Apr 2014 13:51:49 +0200
Subject: [PATCH] allow -fmain-file-name also in driver

This allows overriding the name in special cases such as getting the input
from stdin. Also, fix:
- if the name passed is an absolute path, do not try to prepend anything
- do not prepend / if source comes from stdin and the current dir is /
  (the directory for stdin will be originally considered to be . too,
   but caching in file handling will replace it with equal /)
---
 include/clang/Driver/CC1AsOptions.td  |  2 +-
 include/clang/Driver/CC1Options.td|  2 --
 include/clang/Driver/Options.td   |  3 +++
 lib/CodeGen/CGDebugInfo.cpp   | 25 +
 lib/Driver/Driver.cpp |  6 +++---
 lib/Driver/Tools.cpp  | 14 ++
 lib/Frontend/CompilerInvocation.cpp   |  2 +-
 test/Driver/debug-main-file.S |  2 +-
 test/Driver/debug-main-file.c |  6 ++
 test/Driver/no-integrated-as-win.c|  2 +-
 test/Profile/c-captured.c |  4 ++--
 test/Profile/c-counter-overflows.c|  2 +-
 test/Profile/c-general.c  |  4 ++--
 test/Profile/c-linkage-available_externally.c |  2 +-
 test/Profile/c-linkage.c  |  2 +-
 test/Profile/c-outdated-data.c|  2 +-
 test/Profile/c-unprofiled-blocks.c|  2 +-
 test/Profile/cxx-implicit.cpp |  2 +-
 test/Profile/cxx-lambda.cpp   |  4 ++--
 test/Profile/cxx-linkage.cpp  |  2 +-
 test/Profile/cxx-templates.cpp|  4 ++--
 test/Profile/objc-general.m   |  4 ++--
 tools/driver/cc1as_main.cpp   |  2 +-
 23 files changed, 57 insertions(+), 43 deletions(-)
 create mode 100644 test/Driver/debug-main-file.c

diff --git a/include/clang/Driver/CC1AsOptions.td b/include/clang/Driver/CC1AsOptions.td
index 3e130d0..687a180 100644
--- a/include/clang/Driver/CC1AsOptions.td
+++ b/include/clang/Driver/CC1AsOptions.td
@@ -37,7 +37,7 @@ def msave_temp_labels : Flag[-], msave-temp-labels,
   HelpTextSave temporary labels in the symbol table. 
Note this may change .s semantics, it should almost never be used 
on compiler generated code!;
-def main_file_name : Separate[-], main-file-name,
+def fmain_file_name : Separate[-], fmain-file-name,
   HelpTextMain file name to use for debug info;
 
 //===--===//
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index 3f85c00..b1260f8 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -401,8 +401,6 @@ def fblocks_runtime_optional : Flag[-], fblocks-runtime-optional,
   HelpTextWeakly link in the blocks runtime;
 def fsjlj_exceptions : Flag[-], fsjlj-exceptions,
   HelpTextUse SjLj style exceptions;
-def main_file_name : Separate[-], main-file-name,
-  HelpTextMain file name to use for debug info;
 def fno_wchar : Flag[-], fno-wchar,
   HelpTextDisable C++ builtin

Re: [PATCH] Allow overriding -split-dwarf-file

2014-05-02 Thread Lubos Lunak
On Friday 02 of May 2014, David Blaikie wrote:
 On Fri, Apr 4, 2014 at 9:07 AM, Lubos Lunak l.lu...@centrum.cz wrote:
  On Friday 04 of April 2014, David Blaikie wrote:
  Oops, re-add cfe-commits.
 
  On Fri, Apr 4, 2014 at 8:34 AM, David Blaikie dblai...@gmail.com wrote:
   On Fri, Apr 4, 2014 at 8:24 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   On Friday 04 of April 2014, Eric Christopher wrote:
   ... Why would you want to do this?
  
The compile itself happens in a chroot and the expected and actual
   output locations differ (and don't even exist in the other tree).
  
   In your scenario the .dwo is not side-by-side with the .o? Or are you
   overriding the .o name as well in some way?
 
   The scenario is distributed compiling with Icecream
  (https://github.com/icecc/icecream). If you don't know it, think distcc,
  except more sophisticated in some ways, one of them being that it ships
  the compiler to the remote host and uses it in chroot (which avoids a
  number of problems and allows cross-compiling).
 
   Which means the actual compile run lacks a number of things, like the
  source file itself (piped using stdin), the source file location, or the
  expected output location. The result goes to a temporary .o file, which
  is generally not a problem (I don't think the name of the .o file
  matters), but with split dwarf the .dwo name gets hardcoded to this
  random location in the .o file. For performance reasons there's a chroot
  location per compiler, not per compile, so while I could temporarily
  create the right location, I'm not exactly eager to write the code to do
  that properly with all the locks etc.

 I'm not sure why that would require locks, etc. At least you could
 generate a safe temp directory and put the source file in that
 directory with its intended name - then you just have to correct for
 the directory, but not the file or dwo file names, right? (
 -fdebug-compilation-dir is already there - but, yes, as pointed out it
 should be elevated to a driver option if it's being relied upon)

 Maybe this doesn't work for relative paths? (eg: clang x/y.cpp from
 directory 'z', but I don't recall how clang names the dwo file, the
 comp dir file, etc, in that case)

 It doesn't work for absolute paths.

$ clang++ -c -g -gsplit-dwarf a.cpp -o /somewhere/a.o
$ readelf -wi /somewhere/a.o | grep dwo_name
c   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): /somewhere/a.dwo

 Now how should I get the correct path for the dwo file, without locks and 
whatnot, if the same node gets two such compile jobs at the same time (not 
very likely, but possible) and would therefore need to output two 
different .o files with the same path and filename?

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207756 - write a line marker right before adding included file

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 07:45:08 2014
New Revision: 207756

URL: http://llvm.org/viewvc/llvm-project?rev=207756view=rev
Log:
write a line marker right before adding included file

Enclosing the original #include directive inside #if 0 adds lines,
so warning/errors messages would have the line number off in
In file included from file:line:, so add line marker to fix this.


Added:
cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
cfe/trunk/test/Frontend/rewrite-includes-messages.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes-missing.c
cfe/trunk/test/Frontend/rewrite-includes-modules.c
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207756r1=207755r2=207756view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 07:45:08 
2014
@@ -383,6 +383,7 @@ bool InclusionRewriter::Process(FileID F
   case tok::pp_import: {
 CommentOutDirective(RawLex, HashToken, FromFile, EOL, NextToWrite,
   Line);
+WriteLineInfo(FileName, Line - 1, FileType, EOL, );
 StringRef LineInfoExtra;
 if (const FileChange *Change = FindFileChangeLocation(
 HashToken.getLocation())) {

Added: cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h?rev=207756view=auto
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h (added)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h Thu May  1 
07:45:08 2014
@@ -0,0 +1,4 @@
+void f()
+{
+int unused_variable;
+}

Added: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207756view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (added)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c Thu May  1 07:45:08 2014
@@ -0,0 +1,8 @@
+// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 2 %t.1
+// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
+// RUN: cmp -s %t.1 %t.2
+// expected-no-diagnostics
+// REQUIRES: shell
+
+#include rewrite-includes-messages.h
+#define UNUSED_MACRO

Modified: cfe/trunk/test/Frontend/rewrite-includes-missing.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-missing.c?rev=207756r1=207755r2=207756view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-missing.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-missing.c Thu May  1 07:45:08 2014
@@ -4,4 +4,5 @@
 // CHECK: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include foobar.h
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: {{^}}# 3 {{.*}}rewrite-includes-missing.c{{$}}
 // CHECK-NEXT: {{^}}# 4 {{.*}}rewrite-includes-missing.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes-modules.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-modules.c?rev=207756r1=207755r2=207756view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-modules.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-modules.c Thu May  1 07:45:08 2014
@@ -10,11 +10,13 @@ int foo();
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 5 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 6 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: int foo();{{$}}
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 7 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 8 {{.*[/\\]}}rewrite-includes-modules.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes.c?rev=207756r1=207755r2=207756view=diff

Re: [PATCH] do not warn about unknown pragmas in modes that do not handle them (pr9537) #2

2014-05-01 Thread Lubos Lunak
On Sunday 13 of April 2014, Richard Smith wrote:
 Please also add a test for the #pragma STDC case. Other than that, LGTM.
 Thanks!

 I cannot add a test for it, as such. The problem was hitting an assert in 
Clang's code during setup, it didn't depend on any specific input (I only 
didn't encounter it because of not having assert build when testing it 
originally). If this kind of problem ever shows up, it'll be triggered by a 
number of already existing tests (any that use the call, e.g. all 
of -frewrite-includes tests).

 So I've committed the patch as it was. In case I misunderstood and you can 
explain what you meant exactly, I can add what would be necessary.


 On Fri, Apr 4, 2014 at 3:32 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   This is a re-send of the patch from
 
  http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131202/09469
 6.html, which went without any answers. As can be seen in that mail, the
  original version of the patch has already been committed as r196372 but
  was then reverted because of a problem that this new version solves.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207758 - do not warn about unknown pragmas in modes that do not handle them (pr9537)

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 07:54:03 2014
New Revision: 207758

URL: http://llvm.org/viewvc/llvm-project?rev=207758view=rev
Log:
do not warn about unknown pragmas in modes that do not handle them (pr9537)

And refactor to have just one place in code that sets up the empty
pragma handlers.


Added:
cfe/trunk/test/Preprocessor/ignore-pragmas.c
Modified:
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
cfe/trunk/lib/Lex/Pragma.cpp
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp

Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/Preprocessor.h?rev=207758r1=207757r2=207758view=diff
==
--- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
+++ cfe/trunk/include/clang/Lex/Preprocessor.h Thu May  1 07:54:03 2014
@@ -667,6 +667,9 @@ public:
 RemovePragmaHandler(StringRef(), Handler);
   }
 
+  /// Install empty handlers for all pragmas (making them ignored).
+  void IgnorePragmas();
+
   /// \brief Add the specified comment handler to the preprocessor.
   void addCommentHandler(CommentHandler *Handler);
 

Modified: cfe/trunk/lib/Frontend/FrontendActions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendActions.cpp?rev=207758r1=207757r2=207758view=diff
==
--- cfe/trunk/lib/Frontend/FrontendActions.cpp (original)
+++ cfe/trunk/lib/Frontend/FrontendActions.cpp Thu May  1 07:54:03 2014
@@ -592,7 +592,7 @@ void PreprocessOnlyAction::ExecuteAction
   Preprocessor PP = getCompilerInstance().getPreprocessor();
 
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   Token Tok;
   // Start parsing the specified input file.

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=207758r1=207757r2=207758view=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Thu May  1 07:54:03 2014
@@ -671,7 +671,7 @@ static int MacroIDCompare(const id_macro
 
 static void DoPrintMacros(Preprocessor PP, raw_ostream *OS) {
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // -dM mode just scans and ignores all tokens in the files, then dumps out
   // the macro table at the end.

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=207758r1=207757r2=207758view=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Thu May  1 07:54:03 2014
@@ -1385,3 +1385,25 @@ void Preprocessor::RegisterBuiltinPragma
 AddPragmaHandler(new PragmaRegionHandler(endregion));
   }
 }
+
+/// Ignore all pragmas, useful for modes such as -Eonly which would otherwise
+/// warn about those pragmas being unknown.
+void Preprocessor::IgnorePragmas() {
+  AddPragmaHandler(new EmptyPragmaHandler());
+  // Also ignore all pragmas in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  AddPragmaHandler(clang, new EmptyPragmaHandler());
+  if (PragmaHandler *NS = PragmaHandlers-FindHandler(STDC)) {
+// Preprocessor::RegisterBuiltinPragmas() already registers
+// PragmaSTDC_UnknownHandler as the empty handler, so remove it first,
+// otherwise there will be an assert about a duplicate handler.
+PragmaNamespace *STDCNamespace = NS-getIfNamespace();
+assert(STDCNamespace 
+   Invalid namespace, registered as a regular pragma handler!);
+if (PragmaHandler *Existing = STDCNamespace-FindHandler(, false)) {
+  RemovePragmaHandler(STDC, Existing);
+}
+  }
+  AddPragmaHandler(STDC, new EmptyPragmaHandler());
+}

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207758r1=207757r2=207758view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 07:54:03 
2014
@@ -515,13 +515,7 @@ void clang::RewriteIncludesInInput(Prepr
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
-  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
-  // (because there's nothing 

Re: r207756 - write a line marker right before adding included file

2014-05-01 Thread Lubos Lunak
On Thursday 01 of May 2014, Rafael Espíndola wrote:
 Looks like this broke some bots:

 http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/11226/steps/chec
k-all/logs/Clang%3A%3Arewrite-includes-messages.c

 Yes, I know, give me a minute.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207762 - revert r207756

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 08:37:55 2014
New Revision: 207762

URL: http://llvm.org/viewvc/llvm-project?rev=207762view=rev
Log:
revert r207756

There's nothing wrong with the change itself, but
test/Frontend/rewrite-includes-messages.c fails without another
not-yet-committed fix.


Removed:
cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
cfe/trunk/test/Frontend/rewrite-includes-messages.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes-missing.c
cfe/trunk/test/Frontend/rewrite-includes-modules.c
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207762r1=207761r2=207762view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 08:37:55 
2014
@@ -383,7 +383,6 @@ bool InclusionRewriter::Process(FileID F
   case tok::pp_import: {
 CommentOutDirective(RawLex, HashToken, FromFile, EOL, NextToWrite,
   Line);
-WriteLineInfo(FileName, Line - 1, FileType, EOL, );
 StringRef LineInfoExtra;
 if (const FileChange *Change = FindFileChangeLocation(
 HashToken.getLocation())) {

Removed: cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h?rev=207761view=auto
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h (original)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h (removed)
@@ -1,4 +0,0 @@
-void f()
-{
-int unused_variable;
-}

Removed: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207761view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c (removed)
@@ -1,8 +0,0 @@
-// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 2 %t.1
-// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
-// RUN: cmp -s %t.1 %t.2
-// expected-no-diagnostics
-// REQUIRES: shell
-
-#include rewrite-includes-messages.h
-#define UNUSED_MACRO

Modified: cfe/trunk/test/Frontend/rewrite-includes-missing.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-missing.c?rev=207762r1=207761r2=207762view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-missing.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-missing.c Thu May  1 08:37:55 2014
@@ -4,5 +4,4 @@
 // CHECK: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include foobar.h
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
-// CHECK-NEXT: {{^}}# 3 {{.*}}rewrite-includes-missing.c{{$}}
 // CHECK-NEXT: {{^}}# 4 {{.*}}rewrite-includes-missing.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes-modules.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-modules.c?rev=207762r1=207761r2=207762view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-modules.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-modules.c Thu May  1 08:37:55 2014
@@ -10,13 +10,11 @@ int foo();
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
-// CHECK-NEXT: # 5 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 6 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: int foo();{{$}}
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
-// CHECK-NEXT: # 7 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 8 {{.*[/\\]}}rewrite-includes-modules.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes.c?rev=207762r1=207761r2=207762view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes.c (original)
+++ 

r207764 - do not use 1 for line marker for the main file

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 08:50:44 2014
New Revision: 207764

URL: http://llvm.org/viewvc/llvm-project?rev=207764view=rev
Log:
do not use 1 for line marker for the main file

1 means entering a new file (from a different one), but the main
file is not included from anything (and this would e.g. confuse -Wunused-macros
to not report unused macros in the main file, see pr15610, or also see pr18948).
The line marker is still useful e.g. if the resulting file is renamed or used
via a pipe.


Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207764r1=207763r2=207764view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 08:50:44 
2014
@@ -352,8 +352,11 @@ bool InclusionRewriter::Process(FileID F
 
   StringRef EOL = DetectEOL(FromFile);
 
-  // Per the GNU docs: 1 indicates the start of a new file.
-  WriteLineInfo(FileName, 1, FileType, EOL,  1);
+  // Per the GNU docs: 1 indicates entering a new file.
+  if (FileId == SM.getMainFileID())
+WriteLineInfo(FileName, 1, FileType, EOL, );
+  else
+WriteLineInfo(FileName, 1, FileType, EOL,  1);
 
   if (SM.getFileIDSize(FileId) == 0)
 return false;

Modified: cfe/trunk/test/Frontend/rewrite-includes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes.c?rev=207764r1=207763r2=207764view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes.c Thu May  1 08:50:44 2014
@@ -21,6 +21,7 @@ A(1,2)
 #include rewrite-includes7.h
 #include rewrite-includes8.h
 // ENDCOMPARE
+// CHECK: {{^}}# 1 {{.*}}rewrite-includes.c{{$}}
 // CHECK: {{^}}// STARTCOMPARE{{$}}
 // CHECK-NEXT: {{^}}#define A(a,b) a ## b{{$}}
 // CHECK-NEXT: {{^}}A(1,2){{$}}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Do not use 1 in linemarker for main file in -frewrite-includes

2014-05-01 Thread Lubos Lunak
On Sunday 13 of April 2014, Richard Smith wrote:
 The check for MainFileID and accompanying test LGTM.

 Can you explain what the check for PredefinesFileID is for?

 Without that check, the output can look e.g. like this:
=
# 1 built-in 1 
# 1 a.cpp 
void f() {} 
=

 Which is wrong. Only now that I look at it, what's wrong is rather that 
there's no closing 2 linemarker for built-in.

 So how about this attached patch (on top of the previous one that had the 
predefines check removed)?

 AFAICS, there's 
 no test for that part of the change, and I'm concerned that we could end up
 attributing lines in that FileID to some other file.

 The patch includes a test specifically for the predefines file, although that 
theoretically shouldn't be necessary, since there's no output from the 
predefines file anyway (OutputContentUpTo() skips it).

 On Fri, Apr 4, 2014 at 3:09 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   The -frewrite-includes flag incorrectly uses at the beginning a
  linemarker for the main file with the 1 flag which suggests that the
  contents have been in fact included from another file. This for example
  disables -Wunused-macros, which warns only for macros from the main file:
 
  $ cat a.cpp
  #define FOO 1
  $ clang++ -E -frewrite-includes a.cpp | clang++ -Wall -Wunused-macros -x
  c++ -c -
  $ clang++ -Wall -Wunused-macros -c a.cpp
  a.cpp:1:9: warning: macro is not used [-Wunused-macros]
  #define FOO 1
  ^
  1 warning generated.
 
   The attached patch fixes the code to start the resulting file with the
  correct linemarker.

-- 
 Lubos Lunak
From 92ea65facd7dcb07f44339a8eede8874dd66795b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Thu, 1 May 2014 16:43:03 +0200
Subject: [PATCH] do not use 1 for line marker for the predefines file
 either

Similar to r207764.
---
 lib/Rewrite/Frontend/InclusionRewriter.cpp   | 6 +-
 test/Frontend/rewrite-includes-cli-include.c | 9 +
 2 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 test/Frontend/rewrite-includes-cli-include.c

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index ad8328e..d6a434d 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -250,6 +250,10 @@ void InclusionRewriter::CommentOutDirective(Lexer DirectiveLex,
   do {
 DirectiveLex.LexFromRawLexer(DirectiveToken);
   } while (!DirectiveToken.is(tok::eod)  DirectiveToken.isNot(tok::eof));
+  if (FromFile == PredefinesBuffer) {
+// OutputContentUpTo() would not output anything anyway.
+return;
+  }
   OS  #if 0 /* expanded by -frewrite-includes */  EOL;
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(DirectiveToken.getLocation()) + DirectiveToken.getLength(),
@@ -353,7 +357,7 @@ bool InclusionRewriter::Process(FileID FileId,
   StringRef EOL = DetectEOL(FromFile);
 
   // Per the GNU docs: 1 indicates entering a new file.
-  if (FileId == SM.getMainFileID())
+  if (FileId == SM.getMainFileID() || FileId == PP.getPredefinesFileID())
 WriteLineInfo(FileName, 1, FileType, EOL, );
   else
 WriteLineInfo(FileName, 1, FileType, EOL,  1);
diff --git a/test/Frontend/rewrite-includes-cli-include.c b/test/Frontend/rewrite-includes-cli-include.c
new file mode 100644
index 000..ba96039
--- /dev/null
+++ b/test/Frontend/rewrite-includes-cli-include.c
@@ -0,0 +1,9 @@
+// RUN: not %clang_cc1 -verify -E -frewrite-includes -include %S/Inputs/rewrite-includes2.h %s -o - | FileCheck -strict-whitespace %s
+main_file_line
+// CHECK: {{^}}# 1 built-in{{$}}
+// CHECK-NEXT: {{^}}# 1 {{.*[/\\]Inputs(/|)}}rewrite-includes2.h 1{{$}}
+// CHECK-NEXT: {{^}}included_line2{{$}}
+// CHECK-NEXT: {{^}}# 1 built-in 2{{$}}
+// CHECK-NEXT: {{^}}# 1 {{.*}}rewrite-includes-cli-include.c{{$}}
+// CHECK-NEXT: FileCheck
+// CHECK-NEXT: {{^}}main_file_line{{$}}
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives #2

2014-05-01 Thread Lubos Lunak
On Sunday 13 of April 2014, Richard Smith wrote:
 On Fri, Apr 4, 2014 at 3:47 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   This is a re-send of
 
  http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/09423
 1.html which went without any answer.
 
   See PR15614 for a testcase.

 The combination of -Wunused-macro and -frewrite-includes still doesn't
 really work with this patch applied: if the only use of a macro is within a
 preprocessor directive that -frewrite-includes expands, we'll still warn
 about it. Unfortunately I don't have any great ideas as to how to solve
 this; the least bad idea I have is to add a '#pragma clang macro_used
 BLAH', and emit that for each macro that's used in the -frewrite-includes
 run.

 But that's not directly related to this patch, is it? The patch fixes a 
relatively common case, and even if your rare case remains, the patch is 
still an improvement.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207794 - do not use 1 for line marker for the predefines file either

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 16:10:08 2014
New Revision: 207794

URL: http://llvm.org/viewvc/llvm-project?rev=207794view=rev
Log:
do not use 1 for line marker for the predefines file either

Similar to r207764.


Added:
cfe/trunk/test/Frontend/rewrite-includes-cli-include.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207794r1=207793r2=207794view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 16:10:08 
2014
@@ -250,6 +250,10 @@ void InclusionRewriter::CommentOutDirect
   do {
 DirectiveLex.LexFromRawLexer(DirectiveToken);
   } while (!DirectiveToken.is(tok::eod)  DirectiveToken.isNot(tok::eof));
+  if (FromFile == PredefinesBuffer) {
+// OutputContentUpTo() would not output anything anyway.
+return;
+  }
   OS  #if 0 /* expanded by -frewrite-includes */  EOL;
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(DirectiveToken.getLocation()) + 
DirectiveToken.getLength(),
@@ -353,7 +357,7 @@ bool InclusionRewriter::Process(FileID F
   StringRef EOL = DetectEOL(FromFile);
 
   // Per the GNU docs: 1 indicates entering a new file.
-  if (FileId == SM.getMainFileID())
+  if (FileId == SM.getMainFileID() || FileId == PP.getPredefinesFileID())
 WriteLineInfo(FileName, 1, FileType, EOL, );
   else
 WriteLineInfo(FileName, 1, FileType, EOL,  1);

Added: cfe/trunk/test/Frontend/rewrite-includes-cli-include.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-cli-include.c?rev=207794view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-cli-include.c (added)
+++ cfe/trunk/test/Frontend/rewrite-includes-cli-include.c Thu May  1 16:10:08 
2014
@@ -0,0 +1,9 @@
+// RUN: not %clang_cc1 -verify -E -frewrite-includes -include 
%S/Inputs/rewrite-includes2.h %s -o - | FileCheck -strict-whitespace %s
+main_file_line
+// CHECK: {{^}}# 1 built-in{{$}}
+// CHECK-NEXT: {{^}}# 1 {{.*[/\\]Inputs(/|)}}rewrite-includes2.h 1{{$}}
+// CHECK-NEXT: {{^}}included_line2{{$}}
+// CHECK-NEXT: {{^}}# 1 built-in 2{{$}}
+// CHECK-NEXT: {{^}}# 1 {{.*}}rewrite-includes-cli-include.c{{$}}
+// CHECK-NEXT: FileCheck
+// CHECK-NEXT: {{^}}main_file_line{{$}}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207795 - write a line marker right before adding included file

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 16:11:57 2014
New Revision: 207795

URL: http://llvm.org/viewvc/llvm-project?rev=207795view=rev
Log:
write a line marker right before adding included file

Enclosing the original #include directive inside #if 0 adds lines,
so warning/errors messages would have the line number off in
In file included from file:line:, so add line marker to fix this.


Added:
cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
cfe/trunk/test/Frontend/rewrite-includes-messages.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes-missing.c
cfe/trunk/test/Frontend/rewrite-includes-modules.c
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=207795r1=207794r2=207795view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu May  1 16:11:57 
2014
@@ -390,6 +390,8 @@ bool InclusionRewriter::Process(FileID F
   case tok::pp_import: {
 CommentOutDirective(RawLex, HashToken, FromFile, EOL, NextToWrite,
   Line);
+if (FileId != PP.getPredefinesFileID())
+  WriteLineInfo(FileName, Line - 1, FileType, EOL, );
 StringRef LineInfoExtra;
 if (const FileChange *Change = FindFileChangeLocation(
 HashToken.getLocation())) {

Added: cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h?rev=207795view=auto
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h (added)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes-messages.h Thu May  1 
16:11:57 2014
@@ -0,0 +1,4 @@
+void f()
+{
+int unused_variable;
+}

Added: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207795view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (added)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c Thu May  1 16:11:57 2014
@@ -0,0 +1,8 @@
+// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 2 %t.1
+// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
+// RUN: cmp -s %t.1 %t.2
+// expected-no-diagnostics
+// REQUIRES: shell
+
+#include rewrite-includes-messages.h
+#define UNUSED_MACRO

Modified: cfe/trunk/test/Frontend/rewrite-includes-missing.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-missing.c?rev=207795r1=207794r2=207795view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-missing.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-missing.c Thu May  1 16:11:57 2014
@@ -4,4 +4,5 @@
 // CHECK: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include foobar.h
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: {{^}}# 3 {{.*}}rewrite-includes-missing.c{{$}}
 // CHECK-NEXT: {{^}}# 4 {{.*}}rewrite-includes-missing.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes-modules.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-modules.c?rev=207795r1=207794r2=207795view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-modules.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-modules.c Thu May  1 16:11:57 2014
@@ -10,11 +10,13 @@ int foo();
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 5 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 6 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: int foo();{{$}}
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 7 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import 
*/{{$}}
 // CHECK-NEXT: # 8 {{.*[/\\]}}rewrite-includes-modules.c{{$}}

Modified: cfe/trunk/test/Frontend/rewrite-includes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes.c?rev=207795r1=207794r2=207795view=diff

r207797 - use 'diff' rather than 'cmp -s' in a test

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 16:36:08 2014
New Revision: 207797

URL: http://llvm.org/viewvc/llvm-project?rev=207797view=rev
Log:
use 'diff' rather than 'cmp -s' in a test

That's what all tests use, no idea where I got the latter from.


Modified:
cfe/trunk/test/Frontend/rewrite-includes-messages.c

Modified: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207797r1=207796r2=207797view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c Thu May  1 16:36:08 2014
@@ -1,6 +1,6 @@
 // RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 2 %t.1
 // RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
-// RUN: cmp -s %t.1 %t.2
+// RUN: diff %t.1 %t.2
 // expected-no-diagnostics
 // REQUIRES: shell
 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207808 - do not hide clang stderr output during a test

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 17:40:00 2014
New Revision: 207808

URL: http://llvm.org/viewvc/llvm-project?rev=207808view=rev
Log:
do not hide clang stderr output during a test

I don't know why this fails on the buildbot.


Modified:
cfe/trunk/test/Frontend/rewrite-includes-messages.c

Modified: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207808r1=207807r2=207808view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c Thu May  1 17:40:00 2014
@@ -1,5 +1,5 @@
-// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 2 %t.1
-// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
+// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall 
-Wunused-macros -x c -c - 21 | tee %t.1
+// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 21 | tee %t.2
 // RUN: diff %t.1 %t.2
 // expected-no-diagnostics
 // REQUIRES: shell


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: r207808 - do not hide clang stderr output during a test

2014-05-01 Thread Lubos Lunak
On Friday 02 of May 2014, David Blaikie wrote:
 On Thu, May 1, 2014 at 3:40 PM, Lubos Lunak l.lu...@centrum.cz wrote:
  Author: llunak
  Date: Thu May  1 17:40:00 2014
  New Revision: 207808
 
  URL: http://llvm.org/viewvc/llvm-project?rev=207808view=rev
  Log:
  do not hide clang stderr output during a test
 
  I don't know why this fails on the buildbot.

 What's the buildbot failure look like?

 Until I did this commit, Exit Code: 1.

 This is probably not a change to the test that we should keep in
 perpetuity - it'd be nice to understand/fix the issue, or XFAIL or
 certain platforms, etc, if that's the right answer.

clang: error: unable to execute command: Executable hexagon-as doesn't 
exist!  
(http://lab.llvm.org:8011/builders/clang-hexagon-elf/builds/11260/steps/check-all/logs/Clang::rewrite-includes-messages.c)

 I suppose I should have used -fsyntax-only for the compile. But r207810 has 
already fixed the problem somehow.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r207814 - -fsyntax-only for a test

2014-05-01 Thread Lubos Lunak
Author: llunak
Date: Thu May  1 18:58:20 2014
New Revision: 207814

URL: http://llvm.org/viewvc/llvm-project?rev=207814view=rev
Log:
-fsyntax-only for a test


Modified:
cfe/trunk/test/Frontend/rewrite-includes-messages.c

Modified: cfe/trunk/test/Frontend/rewrite-includes-messages.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-messages.c?rev=207814r1=207813r2=207814view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes-messages.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes-messages.c Thu May  1 18:58:20 2014
@@ -1,5 +1,5 @@
 // RUN: %clang_cc1 -E -frewrite-includes %s -I%S/Inputs/ | %clang_cc1 -Wall 
-fsyntax-only -Wunused-macros -x c - 21  %t.1
-// RUN: %clang_cc1 -I%S/Inputs/ -Wall -Wunused-macros %s 21  %t.2
+// RUN: %clang_cc1 -I%S/Inputs/ -Wall -Wunused-macros -fsyntax-only %s 21  
%t.2
 // RUN: diff %t.1 %t.2 -u
 // expected-no-diagnostics
 


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [patch] Let stddef.h redefine NULL if __need_NULL is set

2014-04-29 Thread Lubos Lunak
On Monday 28 of April 2014, Reid Kleckner wrote:
 Even if we commit this workaround, can we report this as a bug to upstream
 Linux?

 Already done (http://comments.gmane.org/gmane.linux.kernel/1281756). And 
there's actually no public #define NULL in recent Linux headers.

 The test case you have shows how this definition of NULL is broken 
 on x86_64, even in C with gcc:

 $ cat t.c
 #define NULL 0
 int printf(const char *, ...);
 int main() {
   printf(%d %d %d %d %d %d %p\n, 1, 2, 3, 4, 5, 6,
 0xdeadbeefdeadbeefULL); printf(%d %d %d %d %d %d %p\n, 1, 2, 3, 4, 5, 6,
 NULL);
 }

 $ gcc -w t.c -o t  ./t
 1 2 3 4 5 6 0xdeadbeefdeadbeef
 1 2 3 4 5 6 0xdeadbeef

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Warn when a virtual function tries to override a non-virtual one

2014-04-07 Thread Lubos Lunak
On Friday 04 of April 2014, Nico Weber wrote:
 Did you evaluate this on some large codebase for true and false positives?
 The current behavior of -Woverloaded-virtual was carefully chosen to be
 less noisy than gcc's version of the warning (clang's version is low enough
 on noise to be useful, gcc's isn't).

 Ok, I guess this needs a re-think given the reality. Let's scratch this for 
now.

 On Fri, Apr 4, 2014 at 10:54 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   Testcase:
 
  struct B5 {
  void func();
  };
  struct S5 : public B5 {
  virtual void func();
  };
 
   Here most likely S5::func() was meant to override B5::func() but doesn't
  because of missing 'virtual' in the base class. The attached patch warns
  about this case. I added the warning to -Woverloaded-virtual, because
  although technically it is not an overloaded virtual, it is exactly the
  same
  kind of a developer mistake, but if somebody insists I can update the
  patch to make it -Woverridden-non-virtual (which I think is a misnomer
  too :) ) or
  whatever you name it.
 
  --
   Lubos Lunak
 
  ___
  cfe-commits mailing list
  cfe-commits@cs.uiuc.edu
  http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] Allow overriding -split-dwarf-file

2014-04-04 Thread Lubos Lunak

 The option -split-dwarf-file is passed by the driver to the compiler after 
processing -Xclang options, thus overriding any possible explicitly specified 
option:

$ clang++ -c -gsplit-dwarf a.cpp -o a.o -Xclang -split-dwarf-file -Xclang 
b.dwo
$ readelf -wi a.o | grep dwo_name
c   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): a.dwo

 This is because the driver invokes the compiler as
/usr/bin/clang-3.4 -cc1 ... -split-dwarf-file b.dwo -o a.o -x c++ 
a.cpp -split-dwarf-file a.dwo

 The attached patch fixes this. Ok to push?

-- 
 Lubos Lunak
From 993f4a10cf4396ad107a58ff764290ad8b984c99 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 4 Apr 2014 09:12:59 +0200
Subject: [PATCH] allow -split-dwarf-file to be overriden by command line

The driver passed it after -XClang options, thus overriding anything that
was given on the command line.
---
 lib/Driver/Tools.cpp | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp
index 3671880..6262965 100644
--- a/lib/Driver/Tools.cpp
+++ b/lib/Driver/Tools.cpp
@@ -3804,6 +3804,18 @@ void Clang::ConstructJob(Compilation C, const JobAction JA,
   // Forward -fparse-all-comments to -cc1.
   Args.AddAllArgs(CmdArgs, options::OPT_fparse_all_comments);
 
+  // Add the split debug info name to the command lines here so we
+  // can propagate it to the backend.
+  bool SplitDwarf = Args.hasArg(options::OPT_gsplit_dwarf) 
+getToolChain().getTriple().isOSLinux() 
+(isaAssembleJobAction(JA) || isaCompileJobAction(JA));
+  const char *SplitDwarfOut;
+  if (SplitDwarf) {
+CmdArgs.push_back(-split-dwarf-file);
+SplitDwarfOut = SplitDebugName(Args, Inputs);
+CmdArgs.push_back(SplitDwarfOut);
+  }
+
   // Forward -Xclang arguments to -cc1, and -mllvm arguments to the LLVM option
   // parser.
   Args.AddAllArgValues(CmdArgs, options::OPT_Xclang);
@@ -3862,18 +3874,6 @@ void Clang::ConstructJob(Compilation C, const JobAction JA,
 CmdArgs.push_back(Args.MakeArgString(Flags.str()));
   }
 
-  // Add the split debug info name to the command lines here so we
-  // can propagate it to the backend.
-  bool SplitDwarf = Args.hasArg(options::OPT_gsplit_dwarf) 
-getToolChain().getTriple().isOSLinux() 
-(isaAssembleJobAction(JA) || isaCompileJobAction(JA));
-  const char *SplitDwarfOut;
-  if (SplitDwarf) {
-CmdArgs.push_back(-split-dwarf-file);
-SplitDwarfOut = SplitDebugName(Args, Inputs);
-CmdArgs.push_back(SplitDwarfOut);
-  }
-
   // Finally add the compile command to the compilation.
   if (Args.hasArg(options::OPT__SLASH_fallback) 
   Output.getType() == types::TY_Object) {
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] Fix In file included from for files generated with -frewrite-includes

2014-04-04 Thread Lubos Lunak

 Option -frewrite-includes comments out #include directives it replaces by 
enclosing it in #if 0, which moves the included contents, changing their 
perceived line numbers e.g. in the In file included from messages in a 
follow-up compilation:

$ cat b.cpp
#include b.h
$ cat b.h
void f()
{
int unused_variable;
}
$ clang++ -E -frewrite-includes b.cpp | clang++ -Wall -x c++ -c -
In file included from b.cpp:4:
./b.h:3:9: warning: unused variable 'unused_variable' [-Wunused-variable]
int unused_variable;
^
1 warning generated.
$ clang++ -Wall -c b.cpp
In file included from b.cpp:1:
./b.h:3:9: warning: unused variable 'unused_variable' [-Wunused-variable]
int unused_variable;
^
1 warning generated.

 The attached patch fixes this.

-- 
 Lubos Lunak
From 2ccc4c6aa5b7334970fa699a1b99657fa93e9ae5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 21 Feb 2014 00:05:53 +0100
Subject: [PATCH 2/3] write a line marker right before adding included file

Enclosing the original #include directive inside #if 0 adds lines,
so warning/errors messages would have the line number off in
In file included from file:line:, so add line marker to fix this.
---
 lib/Rewrite/Frontend/InclusionRewriter.cpp   |  1 +
 test/Frontend/Inputs/rewrite-includes-messages.h |  4 
 test/Frontend/rewrite-includes-messages.c|  8 
 test/Frontend/rewrite-includes-missing.c |  1 +
 test/Frontend/rewrite-includes-modules.c |  2 ++
 test/Frontend/rewrite-includes.c | 10 ++
 6 files changed, 26 insertions(+)
 create mode 100644 test/Frontend/Inputs/rewrite-includes-messages.h
 create mode 100644 test/Frontend/rewrite-includes-messages.c

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 3704760..cc087d1 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -386,6 +386,7 @@ bool InclusionRewriter::Process(FileID FileId,
   case tok::pp_import: {
 CommentOutDirective(RawLex, HashToken, FromFile, EOL, NextToWrite,
   Line);
+WriteLineInfo(FileName, Line - 1, FileType, EOL, );
 StringRef LineInfoExtra;
 if (const FileChange *Change = FindFileChangeLocation(
 HashToken.getLocation())) {
diff --git a/test/Frontend/Inputs/rewrite-includes-messages.h b/test/Frontend/Inputs/rewrite-includes-messages.h
new file mode 100644
index 000..e5f0eb2
--- /dev/null
+++ b/test/Frontend/Inputs/rewrite-includes-messages.h
@@ -0,0 +1,4 @@
+void f()
+{
+int unused_variable;
+}
diff --git a/test/Frontend/rewrite-includes-messages.c b/test/Frontend/rewrite-includes-messages.c
new file mode 100644
index 000..37b9706
--- /dev/null
+++ b/test/Frontend/rewrite-includes-messages.c
@@ -0,0 +1,8 @@
+// RUN: %clang -E -frewrite-includes %s -I%S/Inputs/ | %clang -Wall -Wunused-macros -x c -c - 2 %t.1
+// RUN: %clang -I%S/Inputs/ -Wall -Wunused-macros -c %s 2 %t.2
+// RUN: cmp -s %t.1 %t.2
+// expected-no-diagnostics
+// REQUIRES: shell
+
+#include rewrite-includes-messages.h
+#define UNUSED_MACRO
diff --git a/test/Frontend/rewrite-includes-missing.c b/test/Frontend/rewrite-includes-missing.c
index da4e209..25a59a0 100644
--- a/test/Frontend/rewrite-includes-missing.c
+++ b/test/Frontend/rewrite-includes-missing.c
@@ -4,4 +4,5 @@
 // CHECK: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include foobar.h
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: {{^}}# 3 {{.*}}rewrite-includes-missing.c{{$}}
 // CHECK-NEXT: {{^}}# 4 {{.*}}rewrite-includes-missing.c{{$}}
diff --git a/test/Frontend/rewrite-includes-modules.c b/test/Frontend/rewrite-includes-modules.c
index 783a967..58d7809 100644
--- a/test/Frontend/rewrite-includes-modules.c
+++ b/test/Frontend/rewrite-includes-modules.c
@@ -10,11 +10,13 @@ int foo();
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 5 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import */{{$}}
 // CHECK-NEXT: # 6 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: int foo();{{$}}
 // CHECK-NEXT: #if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: #include Module/Module.h{{$}}
 // CHECK-NEXT: #endif /* expanded by -frewrite-includes */{{$}}
+// CHECK-NEXT: # 7 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
 // CHECK-NEXT: @import Module; /* clang -frewrite-includes: implicit import */{{$}}
 // CHECK-NEXT: # 8 {{.*[/\\]}}rewrite-includes-modules.c{{$}}
diff --git a/test/Frontend/rewrite-includes.c b/test/Frontend/rewrite-includes.c
index 619d34a..bed87ef 100644
--- a/test/Frontend/rewrite-includes.c
+++ b/test/Frontend/rewrite

[PATCH] Do not use 1 in linemarker for main file in -frewrite-includes

2014-04-04 Thread Lubos Lunak

 The -frewrite-includes flag incorrectly uses at the beginning a linemarker 
for the main file with the 1 flag which suggests that the contents have 
been in fact included from another file. This for example 
disables -Wunused-macros, which warns only for macros from the main file:

$ cat a.cpp
#define FOO 1
$ clang++ -E -frewrite-includes a.cpp | clang++ -Wall -Wunused-macros -x 
c++ -c -
$ clang++ -Wall -Wunused-macros -c a.cpp
a.cpp:1:9: warning: macro is not used [-Wunused-macros]
#define FOO 1
^
1 warning generated.

 The attached patch fixes the code to start the resulting file with the 
correct linemarker.

-- 
 Lubos Lunak
From 27778c2cb8eac373636ea3f50cde73ddd770e79e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Thu, 20 Feb 2014 23:27:44 +0100
Subject: [PATCH 1/3] do not use 1 for line marker for the main file

1 means entering a new file (from a different one), but the main
file is not included from anything (and this would e.g. confuse -Wunused-macros
to not report unused macros in the main file, see pr15610).
The line marker is still useful e.g. if the resulting file is renamed or used
via a pipe.
---
 lib/Rewrite/Frontend/InclusionRewriter.cpp | 7 +--
 test/Frontend/rewrite-includes.c   | 1 +
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 058960d..3704760 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -352,8 +352,11 @@ bool InclusionRewriter::Process(FileID FileId,
 
   StringRef EOL = DetectEOL(FromFile);
 
-  // Per the GNU docs: 1 indicates the start of a new file.
-  WriteLineInfo(FileName, 1, FileType, EOL,  1);
+  // Per the GNU docs: 1 indicates entering a new file.
+  if (FileId == SM.getMainFileID())
+WriteLineInfo(FileName, 1, FileType, EOL, );
+  else if (FileId != PP.getPredefinesFileID())
+WriteLineInfo(FileName, 1, FileType, EOL,  1);
 
   if (SM.getFileIDSize(FileId) == 0)
 return false;
diff --git a/test/Frontend/rewrite-includes.c b/test/Frontend/rewrite-includes.c
index 2158dd0..619d34a 100644
--- a/test/Frontend/rewrite-includes.c
+++ b/test/Frontend/rewrite-includes.c
@@ -21,6 +21,7 @@ A(1,2)
 #include rewrite-includes7.h
 #include rewrite-includes8.h
 // ENDCOMPARE
+// CHECK: {{^}}# 1 {{.*}}rewrite-includes.c{{$}}
 // CHECK: {{^}}// STARTCOMPARE{{$}}
 // CHECK-NEXT: {{^}}#define A(a,b) a ## b{{$}}
 // CHECK-NEXT: {{^}}A(1,2){{$}}
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] do not warn about unknown pragmas in modes that do not handle them (pr9537) #2

2014-04-04 Thread Lubos Lunak

 This is a re-send of the patch from 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131202/094696.html 
, 
which went without any answers. As can be seen in that mail, the original 
version of the patch has already been committed as r196372 but was then 
reverted because of a problem that this new version solves.

-- 
 Lubos Lunak
From ff544b38587446d5a89e430a4a7ee7a777c867e0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 23:42:16 +0100
Subject: [PATCH] do not warn about unknown pragmas in modes that do not handle
 them (pr9537)

And refactor to have just one place in code that sets up the empty
pragma handlers.
---
 include/clang/Lex/Preprocessor.h   |  3 +++
 lib/Frontend/FrontendActions.cpp   |  2 +-
 lib/Frontend/PrintPreprocessedOutput.cpp   |  2 +-
 lib/Lex/Pragma.cpp | 22 ++
 lib/Rewrite/Frontend/InclusionRewriter.cpp |  8 +---
 test/Preprocessor/ignore-pragmas.c | 10 ++
 6 files changed, 38 insertions(+), 9 deletions(-)
 create mode 100644 test/Preprocessor/ignore-pragmas.c

diff --git a/include/clang/Lex/Preprocessor.h b/include/clang/Lex/Preprocessor.h
index 2491011..6822424 100644
--- a/include/clang/Lex/Preprocessor.h
+++ b/include/clang/Lex/Preprocessor.h
@@ -643,6 +643,9 @@ public:
 RemovePragmaHandler(StringRef(), Handler);
   }
 
+  /// Install empty handlers for all pragmas (making them ignored).
+  void IgnorePragmas();
+
   /// \brief Add the specified comment handler to the preprocessor.
   void addCommentHandler(CommentHandler *Handler);
 
diff --git a/lib/Frontend/FrontendActions.cpp b/lib/Frontend/FrontendActions.cpp
index a3ab1be..88044f2 100644
--- a/lib/Frontend/FrontendActions.cpp
+++ b/lib/Frontend/FrontendActions.cpp
@@ -485,7 +485,7 @@ void PreprocessOnlyAction::ExecuteAction() {
   Preprocessor PP = getCompilerInstance().getPreprocessor();
 
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   Token Tok;
   // Start parsing the specified input file.
diff --git a/lib/Frontend/PrintPreprocessedOutput.cpp b/lib/Frontend/PrintPreprocessedOutput.cpp
index f3393bf..87fbd04 100644
--- a/lib/Frontend/PrintPreprocessedOutput.cpp
+++ b/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -704,7 +704,7 @@ static int MacroIDCompare(const id_macro_pair *LHS, const id_macro_pair *RHS) {
 
 static void DoPrintMacros(Preprocessor PP, raw_ostream *OS) {
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // -dM mode just scans and ignores all tokens in the files, then dumps out
   // the macro table at the end.
diff --git a/lib/Lex/Pragma.cpp b/lib/Lex/Pragma.cpp
index e4059ee..b9f40d9 100644
--- a/lib/Lex/Pragma.cpp
+++ b/lib/Lex/Pragma.cpp
@@ -1401,3 +1401,25 @@ void Preprocessor::RegisterBuiltinPragmas() {
 AddPragmaHandler(new PragmaRegionHandler(endregion));
   }
 }
+
+/// Ignore all pragmas, useful for modes such as -Eonly which would otherwise
+/// warn about those pragmas being unknown.
+void Preprocessor::IgnorePragmas() {
+  AddPragmaHandler(new EmptyPragmaHandler());
+  // Also ignore all pragmas in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  AddPragmaHandler(clang, new EmptyPragmaHandler());
+  if (PragmaHandler *NS = PragmaHandlers-FindHandler(STDC)) {
+// Preprocessor::RegisterBuiltinPragmas() already registers
+// PragmaSTDC_UnknownHandler as the empty handler, so remove it first,
+// otherwise there will be an assert about a duplicate handler.
+PragmaNamespace *STDCNamespace = NS-getIfNamespace();
+assert(STDCNamespace 
+   Invalid namespace, registered as a regular pragma handler!);
+if (PragmaHandler *Existing = STDCNamespace-FindHandler(, false)) {
+  RemovePragmaHandler(STDC, Existing);
+}
+  }
+  AddPragmaHandler(STDC, new EmptyPragmaHandler());
+}
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 176ea3f..a3b6c49 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -518,13 +518,7 @@ void clang::RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS,
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
-  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
-  // (because there's nothing to handle them).
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
-  // Ignore also all pragma in all namespaces created
-  // in Preprocessor::RegisterBuiltinPragmas().
-  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
-  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // First let the preprocessor process

[PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives #2

2014-04-04 Thread Lubos Lunak

 This is a re-send of 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/094231.html 
which went without any answer.

 See PR15614 for a testcase.

-- 
 Lubos Lunak
From 710be67e5d01095a723a032676ea178193172b68 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@suse.cz
Date: Sun, 28 Jul 2013 11:32:55 +0200
Subject: [PATCH] do not emit -Wunused-macros warnings in -frewrite-includes
 mode (PR15614)

-frewrite-includes calls PP.SetMacroExpansionOnlyInDirectives() to avoid
macro expansions that are useless in that mode, but this can lead
to -Wunused-macros false positives. As -frewrite-includes does not emit
normal warnings, block -Wunused-macros too.
---
 lib/Lex/PPDirectives.cpp  | 5 +
 test/Frontend/rewrite-includes-warnings.c | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/Lex/PPDirectives.cpp b/lib/Lex/PPDirectives.cpp
index 57dc495..f0e9b29 100644
--- a/lib/Lex/PPDirectives.cpp
+++ b/lib/Lex/PPDirectives.cpp
@@ -647,6 +647,9 @@ public:
   pp-DisableMacroExpansion = false;
   }
   ~ResetMacroExpansionHelper() {
+restore();
+  }
+  void restore() {
 PP-DisableMacroExpansion = save;
   }
 private:
@@ -758,6 +761,7 @@ void Preprocessor::HandleDirective(Token Result) {
 
 // C99 6.10.3 - Macro Replacement.
 case tok::pp_define:
+  helper.restore();
   return HandleDefineDirective(Result, ImmediatelyAfterTopLevelIfndef);
 case tok::pp_undef:
   return HandleUndefDirective(Result);
@@ -2105,6 +2109,7 @@ void Preprocessor::HandleDefineDirective(Token DefineTok,
   // If we need warning for not using the macro, add its location in the
   // warn-because-unused-macro set. If it gets used it will be removed from set.
   if (getSourceManager().isInMainFile(MI-getDefinitionLoc()) 
+  !DisableMacroExpansion 
   Diags-getDiagnosticLevel(diag::pp_macro_not_used,
   MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored) {
 MI-setIsWarnIfUnused(true);
diff --git a/test/Frontend/rewrite-includes-warnings.c b/test/Frontend/rewrite-includes-warnings.c
index 1fb98db..c4f38ed 100644
--- a/test/Frontend/rewrite-includes-warnings.c
+++ b/test/Frontend/rewrite-includes-warnings.c
@@ -1,4 +1,9 @@
-// RUN: %clang_cc1 -verify -Wall -Wextra -E -frewrite-includes %s
+// RUN: %clang_cc1 -verify -Wall -Wextra -Wunused-macros -E -frewrite-includes %s
 // expected-no-diagnostics
 
+// PR14831
 #pragma GCC visibility push (default)
+
+// PR15614
+#define FOO 1
+int foo = FOO;
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR12463 : Warnings about nonsensical comparisons are disabled if macro expansion is involved #2

2014-04-04 Thread Lubos Lunak

 This is a reduced version of the original patch for PR12463 that handles only 
string comparisons (I don't care about arrays enough to deal with the details 
and there the problem is unlikely to happen anyway, but the problem is more 
likely with strings if e.g. refactoring).

-- 
 Lubos Lunak
From aa0ab874f8052d33aa256840d898b71e983f6388 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 17:36:30 +0100
Subject: [PATCH] warn about string literal comparisons even in macros
 (pr12463)

They are unspecified even in macros.
---
 lib/Sema/SemaExpr.cpp | 12 +++-
 test/Sema/exprs.c |  8 
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/lib/Sema/SemaExpr.cpp b/lib/Sema/SemaExpr.cpp
index 7894682..dbcc690 100644
--- a/lib/Sema/SemaExpr.cpp
+++ b/lib/Sema/SemaExpr.cpp
@@ -7783,22 +7783,24 @@ QualType Sema::CheckCompareOperands(ExprResult LHS, ExprResult RHS,
 
   if (!LHSType-hasFloatingRepresentation() 
   !(LHSType-isBlockPointerType()  IsRelational) 
-  !LHS.get()-getLocStart().isMacroID() 
-  !RHS.get()-getLocStart().isMacroID() 
   ActiveTemplateInstantiations.empty()) {
 // For non-floating point types, check for self-comparisons of the form
 // x == x, x != x, x  x, etc.  These always evaluate to a constant, and
 // often indicate logic errors in the program.
 //
 // NOTE: Don't warn about comparison expressions resulting from macro
-// expansion. Also don't warn about comparisons which are only self
+// expansion, unless they do not make any sense at all.
+// Also don't warn about comparisons which are only self
 // comparisons within a template specialization. The warnings should catch
 // obvious cases in the definition of the template anyways. The idea is to
 // warn when the typed comparison operator will always evaluate to the same
 // result.
+bool InMacro = LHS.get()-getLocStart().isMacroID() ||
+   RHS.get()-getLocStart().isMacroID();
 ValueDecl *DL = getCompareDecl(LHSStripped);
 ValueDecl *DR = getCompareDecl(RHSStripped);
-if (DL  DR  DL == DR  !IsWithinTemplateSpecialization(DL)) {
+if (DL  DR  DL == DR  !IsWithinTemplateSpecialization(DL) 
+!InMacro) {
   DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
0 // self-
(Opc == BO_EQ
@@ -7806,7 +7808,7 @@ QualType Sema::CheckCompareOperands(ExprResult LHS, ExprResult RHS,
   || Opc == BO_GE));
 } else if (DL  DR  LHSType-isArrayType()  RHSType-isArrayType() 
!DL-getType()-isReferenceType() 
-   !DR-getType()-isReferenceType()) {
+   !DR-getType()-isReferenceType()  !InMacro) {
 // what is it always going to eval to?
 char always_evals_to;
 switch(Opc) {
diff --git a/test/Sema/exprs.c b/test/Sema/exprs.c
index 2fb17e4..3e90146 100644
--- a/test/Sema/exprs.c
+++ b/test/Sema/exprs.c
@@ -125,6 +125,14 @@ int test12b(const char *X) {
   return sizeof(X == foo); // no-warning
 }
 
+// PR12463
+#define FOO_LITERAL foo
+#define STRING_LITERAL_COMPARE a == b
+int test12c(const char *X) {
+  return X == FOO_LITERAL;  // expected-warning {{comparison against a string literal is unspecified (use strncmp instead)}}
+  return STRING_LITERAL_COMPARE; // expected-warning {{comparison against a string literal is unspecified (use strncmp instead)}}
+}
+
 // rdar://6719156
 void test13(
 void (^P)()) { // expected-error {{blocks support disabled - compile with -fblocks}}
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] Handle properly somewhat special cases of -main-file-name

2014-04-04 Thread Lubos Lunak

 The handling of -main-file-name in CGDebugInfo::CreateCompileUnit() can 
result in incorrect DW_AT_name in somewhat special cases:

1)
$ touch /tmp/a.cpp
$ 
clang++ -Wall -c /tmp/a.cpp -g -o /tmp/a.o -Xclang -main-file-name -Xclang 
/new/path/a.cpp
$ readelf -wi /tmp/a.o | grep DW_AT_name
12   DW_AT_name: (indirect string, offset: 
0x15): /tmp/new/path/a.cpp

2)
$ touch /tmp/a.cpp
$ cd /
$ cat /tmp/a.cpp | clang++ -Wall -x 
c++ -c - -g -o /tmp/a.o -Xclang -main-file-name -Xclang a.cpp
$ readelf -wi /tmp/a.o | grep DW_AT_name
12   DW_AT_name: (indirect string, offset: 0x15): /a.cpp

 The attached patch fixes those. Ok to commit?

-- 
 Lubos Lunak
From 4d532ab3ae69357e98dc50c02944b30be156090a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 4 Apr 2014 13:51:49 +0200
Subject: [PATCH] handle properly somewhat special cases of -main-file-name

- if the name passed is an absolute path, do not try to prepend anything
- do not prepend / if source comes from stdin and the current dir is /
  (the directory for stdin will be originally considered to be . too,
   but caching in file handling will replace it with equal /)
---
 lib/CodeGen/CGDebugInfo.cpp | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/lib/CodeGen/CGDebugInfo.cpp b/lib/CodeGen/CGDebugInfo.cpp
index 0e94b51..c580770 100644
--- a/lib/CodeGen/CGDebugInfo.cpp
+++ b/lib/CodeGen/CGDebugInfo.cpp
@@ -322,18 +322,19 @@ void CGDebugInfo::CreateCompileUnit() {
   std::string MainFileName = CGM.getCodeGenOpts().MainFileName;
   if (MainFileName.empty())
 MainFileName = unknown;
-
-  // The main file name provided via the -main-file-name option contains just
-  // the file name itself with no path information. This file name may have had
-  // a relative path, so we look into the actual file entry for the main
-  // file to determine the real absolute path for the file.
-  std::string MainFileDir;
-  if (const FileEntry *MainFile = SM.getFileEntryForID(SM.getMainFileID())) {
-MainFileDir = MainFile-getDir()-getName();
-if (MainFileDir != .) {
-  llvm::SmallString1024 MainFileDirSS(MainFileDir);
-  llvm::sys::path::append(MainFileDirSS, MainFileName);
-  MainFileName = MainFileDirSS.str();
+  else if (!llvm::sys::path::is_absolute(MainFileName)) {
+// The main file name provided via the -main-file-name option contains just
+// the file name itself with no path information. This file name may have had
+// a relative path, so we look into the actual file entry for the main
+// file to determine the real absolute path for the file.
+std::string MainFileDir;
+if (const FileEntry *MainFile = SM.getFileEntryForID(SM.getMainFileID())) {
+  MainFileDir = MainFile-getDir()-getName();
+  if (MainFileDir != .  MainFile-getName() != StringRef(stdin)) {
+llvm::SmallString1024 MainFileDirSS(MainFileDir);
+llvm::sys::path::append(MainFileDirSS, MainFileName);
+MainFileName = MainFileDirSS.str();
+  }
 }
   }
 
-- 
1.8.4.5

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Allow overriding -split-dwarf-file

2014-04-04 Thread Lubos Lunak
On Friday 04 of April 2014, Eric Christopher wrote:
 ... Why would you want to do this?

 The compile itself happens in a chroot and the expected and actual output 
locations differ (and don't even exist in the other tree). I could do with 
changing DW_AT_GNU_dwo_name explicitly after the build, but that seems 
needlessly complex given that this seems to be exactly what the option does. 
I don't see why I would be allowed to override any option except for this 
one.

 -eric

 On Apr 4, 2014 12:26 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   The option -split-dwarf-file is passed by the driver to the compiler
  after processing -Xclang options, thus overriding any possible explicitly
  specified
  option:
 
  $ clang++ -c -gsplit-dwarf a.cpp -o a.o -Xclang -split-dwarf-file -Xclang
  b.dwo
  $ readelf -wi a.o | grep dwo_name
  c   DW_AT_GNU_dwo_name: (indirect string, offset: 0x0): a.dwo
 
   This is because the driver invokes the compiler as
  /usr/bin/clang-3.4 -cc1 ... -split-dwarf-file b.dwo -o a.o -x c++
  a.cpp -split-dwarf-file a.dwo
 
   The attached patch fixes this. Ok to push?

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Allow overriding -split-dwarf-file

2014-04-04 Thread Lubos Lunak
On Friday 04 of April 2014, David Blaikie wrote:
 Oops, re-add cfe-commits.

 On Fri, Apr 4, 2014 at 8:34 AM, David Blaikie dblai...@gmail.com wrote:
  On Fri, Apr 4, 2014 at 8:24 AM, Lubos Lunak l.lu...@centrum.cz wrote:
  On Friday 04 of April 2014, Eric Christopher wrote:
  ... Why would you want to do this?
 
   The compile itself happens in a chroot and the expected and actual
  output locations differ (and don't even exist in the other tree).
 
  In your scenario the .dwo is not side-by-side with the .o? Or are you
  overriding the .o name as well in some way?

 The scenario is distributed compiling with Icecream 
(https://github.com/icecc/icecream). If you don't know it, think distcc, 
except more sophisticated in some ways, one of them being that it ships the 
compiler to the remote host and uses it in chroot (which avoids a number of 
problems and allows cross-compiling).

 Which means the actual compile run lacks a number of things, like the source 
file itself (piped using stdin), the source file location, or the expected 
output location. The result goes to a temporary .o file, which is generally 
not a problem (I don't think the name of the .o file matters), but with split 
dwarf the .dwo name gets hardcoded to this random location in the .o file. 
For performance reasons there's a chroot location per compiler, not per 
compile, so while I could temporarily create the right location, I'm not 
exactly eager to write the code to do that properly with all the locks etc. 
when I could use a compiler option that just sets one dwarf info field, if 
only I actually could use it.

 If you want a precedent, there's already -fdebug-compilation-dir, which 
AFAICT is exactly the same, just with a different dwarf info field.

  I could do with
  changing DW_AT_GNU_dwo_name explicitly after the build, but that seems
  needlessly complex given that this seems to be exactly what the option
  does. I don't see why I would be allowed to override any option except
  for this one.
 
  -Xclang and the underlying driver arguments aren't really a
  stable/guaranteed interface. I'd be more inclined to accept this
  change if it were just for some debugging, but since it sounds like
  you want to rely on it, it's good for us to understand the goal and
  perhaps suggest or provide the best way of achieving it long-term.

 It's stable/guaranteed enough for me, and I'd rather have a clean solution 
that maybe breaks one day than something hackish the whole time.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] Handle properly somewhat special cases of -main-file-name

2014-04-04 Thread Lubos Lunak
On Friday 04 of April 2014, David Blaikie wrote:
 The comment in CGDebugInfo.cpp says that -main-file-name will contain
 only the file name, with no path information. Are there cases where
 that is not true when -main-file-name is passed from the Clang driver,
 rather than by the user in your example below?

 If the driver provides this guarantee and the user violates it when
 passing an undocumented flag manually, I don't see a need to support
 it - but if there is such a need, it'd be good to
 understand/documemnt/discuss it.

 I think the driver always only passes the filename, but I do pass it 
explicitly, since I feed the source from stdin and the source or even its 
directory don't exist (distributed compiling, the same way with the patch 
for -dwarf-split-file).

 And actually case 2) without using the option explicitly results in 
DW_AT_name becoming /- (I don't know why the driver doesn't simply pass the 
name as it is, which wouldn't need the code that attempts to rebuild it 
later).

 As for undocumented, the documentation status of the option is about the 
same like with many others - it's just in the .td file including its 
description. The description says quite clearly what the option does, it 
doesn't say it's internal, it works fine (except for these small problems), I 
even checked the sources to be sure, and I don't see why Clang should forbid 
usage of the option if I know what I'm doing (and would have to resort to 
ugly hacks otherwise).

 On Fri, Apr 4, 2014 at 5:02 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   The handling of -main-file-name in CGDebugInfo::CreateCompileUnit() can
  result in incorrect DW_AT_name in somewhat special cases:
 
  1)
  $ touch /tmp/a.cpp
  $
  clang++ -Wall -c /tmp/a.cpp -g -o /tmp/a.o -Xclang -main-file-name
  -Xclang /new/path/a.cpp $ readelf -wi /tmp/a.o | grep DW_AT_name
  12   DW_AT_name: (indirect string, offset:
  0x15): /tmp/new/path/a.cpp
 
  2)
  $ touch /tmp/a.cpp
  $ cd /
  $ cat /tmp/a.cpp | clang++ -Wall -x
  c++ -c - -g -o /tmp/a.o -Xclang -main-file-name -Xclang a.cpp
  $ readelf -wi /tmp/a.o | grep DW_AT_name
  12   DW_AT_name: (indirect string, offset: 0x15): /a.cpp
 
   The attached patch fixes those. Ok to commit?
-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] Warn when a virtual function tries to override a non-virtual one

2014-04-04 Thread Lubos Lunak

 Testcase:

struct B5 {
void func();
};
struct S5 : public B5 {
virtual void func();
};

 Here most likely S5::func() was meant to override B5::func() but doesn't 
because of missing 'virtual' in the base class. The attached patch warns 
about this case. I added the warning to -Woverloaded-virtual, because 
although technically it is not an overloaded virtual, it is exactly the same 
kind of a developer mistake, but if somebody insists I can update the patch 
to make it -Woverridden-non-virtual (which I think is a misnomer too :) ) or 
whatever you name it.

-- 
 Lubos Lunak
From 5da1b420e4b0fd7c828876aaff31cb915687a1ec Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Fri, 4 Apr 2014 19:43:48 +0200
Subject: [PATCH] warn when a virtual function tries to override a non-virtual
 one

---
 include/clang/Basic/DiagnosticSemaKinds.td |  5 
 lib/Sema/SemaDecl.cpp  | 37 ++
 test/SemaCXX/warn-overloaded-virtual.cpp   |  8 +++
 3 files changed, 41 insertions(+), 9 deletions(-)

diff --git a/include/clang/Basic/DiagnosticSemaKinds.td b/include/clang/Basic/DiagnosticSemaKinds.td
index fad654f..90a8aeb 100644
--- a/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/include/clang/Basic/DiagnosticSemaKinds.td
@@ -5176,6 +5176,11 @@ def note_hidden_overloaded_virtual_declared_here : Note
   volatile and restrict|const, volatile, and restrict}2 vs 
   %select{none|const|restrict|const and restrict|volatile|const and volatile|
   volatile and restrict|const, volatile, and restrict}3)}1;
+def warn_virtual_function_overriding_non_virtual : Warning
+  virtual %q0 does not override non-virtual function in a base class,
+  InGroupOverloadedVirtual, DefaultIgnore;
+def note_overridden_non_virtual_declared_here : Note
+  non-virtual function %q0 declared here;
 def warn_using_directive_in_header : Warning
   using namespace directive in global context in header,
   InGroupHeaderHygiene, DefaultIgnore;
diff --git a/lib/Sema/SemaDecl.cpp b/lib/Sema/SemaDecl.cpp
index 43d855c..f447692 100644
--- a/lib/Sema/SemaDecl.cpp
+++ b/lib/Sema/SemaDecl.cpp
@@ -5973,6 +5973,8 @@ struct FindOverriddenMethodData {
 /// \brief Member lookup function that determines whether a given C++
 /// method overrides a method in a base class, to be used with
 /// CXXRecordDecl::lookupInBases().
+/// Note that this returns a method in a base class even if that method
+/// is not virtual and thus not actually overridden (to be used for a warning).
 static bool FindOverriddenMethod(const CXXBaseSpecifier *Specifier,
  CXXBasePath Path,
  void *UserData) {
@@ -5997,7 +5999,7 @@ static bool FindOverriddenMethod(const CXXBaseSpecifier *Specifier,
Path.Decls = Path.Decls.slice(1)) {
 NamedDecl *D = Path.Decls.front();
 if (CXXMethodDecl *MD = dyn_castCXXMethodDecl(D)) {
-  if (MD-isVirtual()  !Data-S-IsOverload(Data-Method, MD, false))
+  if (!Data-S-IsOverload(Data-Method, MD, false))
 return true;
 }
   }
@@ -6041,17 +6043,34 @@ bool Sema::AddOverriddenMethods(CXXRecordDecl *DC, CXXMethodDecl *MD) {
   bool hasDeletedOverridenMethods = false;
   bool hasNonDeletedOverridenMethods = false;
   bool AddedAny = false;
+  bool ignoreOverloadedVirtual =
+  (Diags.getDiagnosticLevel(diag::warn_overloaded_virtual,
+MD-getLocation()) ==
+   DiagnosticsEngine::Ignored);
   if (DC-lookupInBases(FindOverriddenMethod, Data, Paths)) {
 for (auto *I : Paths.found_decls()) {
   if (CXXMethodDecl *OldMD = dyn_castCXXMethodDecl(I)) {
-MD-addOverriddenMethod(OldMD-getCanonicalDecl());
-if (!CheckOverridingFunctionReturnType(MD, OldMD) 
-!CheckOverridingFunctionAttributes(MD, OldMD) 
-!CheckOverridingFunctionExceptionSpec(MD, OldMD) 
-!CheckIfOverriddenFunctionIsMarkedFinal(MD, OldMD)) {
-  hasDeletedOverridenMethods |= OldMD-isDeleted();
-  hasNonDeletedOverridenMethods |= !OldMD-isDeleted();
-  AddedAny = true;
+if (OldMD-isVirtual()) {
+  MD-addOverriddenMethod(OldMD-getCanonicalDecl());
+  if (!CheckOverridingFunctionReturnType(MD, OldMD) 
+  !CheckOverridingFunctionAttributes(MD, OldMD) 
+  !CheckOverridingFunctionExceptionSpec(MD, OldMD) 
+  !CheckIfOverriddenFunctionIsMarkedFinal(MD, OldMD)) {
+hasDeletedOverridenMethods |= OldMD-isDeleted();
+hasNonDeletedOverridenMethods |= !OldMD-isDeleted();
+AddedAny = true;
+  }
+} else {
+  // Warn if this method has virtual explicitly written but the one
+  // in a base class is not virtual.
+  if (!ignoreOverloadedVirtual  MD-isVirtualAsWritten()) {
+Diag(MD-getLocation(),
+ diag::warn_virtual_function_overriding_non_virtual

r196372 - do not warn about unknown pragmas in modes that do not handle them (pr9537)

2013-12-04 Thread Lubos Lunak
Author: llunak
Date: Wed Dec  4 04:21:41 2013
New Revision: 196372

URL: http://llvm.org/viewvc/llvm-project?rev=196372view=rev
Log:
do not warn about unknown pragmas in modes that do not handle them (pr9537)

And refactor to have just one place in code that sets up the empty
pragma handlers.


Modified:
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
cfe/trunk/lib/Lex/Pragma.cpp
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp

Modified: cfe/trunk/include/clang/Lex/Preprocessor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/Preprocessor.h?rev=196372r1=196371r2=196372view=diff
==
--- cfe/trunk/include/clang/Lex/Preprocessor.h (original)
+++ cfe/trunk/include/clang/Lex/Preprocessor.h Wed Dec  4 04:21:41 2013
@@ -643,6 +643,9 @@ public:
 RemovePragmaHandler(StringRef(), Handler);
   }
 
+  /// Install empty handlers for all pragmas (making them ignored).
+  void IgnorePragmas();
+
   /// \brief Add the specified comment handler to the preprocessor.
   void addCommentHandler(CommentHandler *Handler);
 

Modified: cfe/trunk/lib/Frontend/FrontendActions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/FrontendActions.cpp?rev=196372r1=196371r2=196372view=diff
==
--- cfe/trunk/lib/Frontend/FrontendActions.cpp (original)
+++ cfe/trunk/lib/Frontend/FrontendActions.cpp Wed Dec  4 04:21:41 2013
@@ -485,7 +485,7 @@ void PreprocessOnlyAction::ExecuteAction
   Preprocessor PP = getCompilerInstance().getPreprocessor();
 
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   Token Tok;
   // Start parsing the specified input file.

Modified: cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp?rev=196372r1=196371r2=196372view=diff
==
--- cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp (original)
+++ cfe/trunk/lib/Frontend/PrintPreprocessedOutput.cpp Wed Dec  4 04:21:41 2013
@@ -704,7 +704,7 @@ static int MacroIDCompare(const id_macro
 
 static void DoPrintMacros(Preprocessor PP, raw_ostream *OS) {
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // -dM mode just scans and ignores all tokens in the files, then dumps out
   // the macro table at the end.

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=196372r1=196371r2=196372view=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Wed Dec  4 04:21:41 2013
@@ -1401,3 +1401,14 @@ void Preprocessor::RegisterBuiltinPragma
 AddPragmaHandler(new PragmaRegionHandler(endregion));
   }
 }
+
+/// Ignore all pragmas, useful for modes such as -Eonly which would otherwise
+/// warn about those pragmas being unknown.
+void Preprocessor::IgnorePragmas() {
+  AddPragmaHandler(new EmptyPragmaHandler());
+  // Also ignore all pragmas in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  AddPragmaHandler(clang, new EmptyPragmaHandler());
+  AddPragmaHandler(STDC, new EmptyPragmaHandler());
+}

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=196372r1=196371r2=196372view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Wed Dec  4 04:21:41 
2013
@@ -518,13 +518,7 @@ void clang::RewriteIncludesInInput(Prepr
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
-  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
-  // (because there's nothing to handle them).
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
-  // Ignore also all pragma in all namespaces created
-  // in Preprocessor::RegisterBuiltinPragmas().
-  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
-  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: r196372 - do not warn about unknown pragmas in modes that do not handle them (pr9537)

2013-12-04 Thread Lubos Lunak
On Wednesday 04 of December 2013, NAKAMURA Takumi wrote:
 I have reverted this. It triggered crashes on check-clang with +Asserts.

 http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/11922

 It seems unknown pragmas in STDC namespace are handled specially. Ok to push 
the patch again with the attached addition? All tests now pass even with 
assertions enabled here.

 2013/12/4 Joerg Sonnenberger jo...@britannica.bec.de:
  On Wed, Dec 04, 2013 at 10:21:41AM -, Lubos Lunak wrote:
  Author: llunak
  Date: Wed Dec  4 04:21:41 2013
  New Revision: 196372
 
  URL: http://llvm.org/viewvc/llvm-project?rev=196372view=rev
  Log:
  do not warn about unknown pragmas in modes that do not handle them
  (pr9537)
 
  And refactor to have just one place in code that sets up the empty
  pragma handlers.
 
  Test case?

 ... Subversion ... It actually is in the patch, I'll remember to svn add it.

  Otherwise, thanks for looking at this. Bill -- is it harmless 
  enough to include in 3.4?

-- 
 Lubos Lunak
diff --git a/lib/Lex/Pragma.cpp b/lib/Lex/Pragma.cpp
index 61bd917..b9f40d9 100644
--- a/lib/Lex/Pragma.cpp
+++ b/lib/Lex/Pragma.cpp
@@ -1410,5 +1410,16 @@ void Preprocessor::IgnorePragmas() {
   // in Preprocessor::RegisterBuiltinPragmas().
   AddPragmaHandler(GCC, new EmptyPragmaHandler());
   AddPragmaHandler(clang, new EmptyPragmaHandler());
+  if (PragmaHandler *NS = PragmaHandlers-FindHandler(STDC)) {
+// Preprocessor::RegisterBuiltinPragmas() already registers
+// PragmaSTDC_UnknownHandler as the empty handler, so remove it first,
+// otherwise there will be an assert about a duplicate handler.
+PragmaNamespace *STDCNamespace = NS-getIfNamespace();
+assert(STDCNamespace 
+   Invalid namespace, registered as a regular pragma handler!);
+if (PragmaHandler *Existing = STDCNamespace-FindHandler(, false)) {
+  RemovePragmaHandler(STDC, Existing);
+}
+  }
   AddPragmaHandler(STDC, new EmptyPragmaHandler());
 }
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: r195910 - InclusionRewriter: Avoid duplicated BOM check

2013-12-03 Thread Lubos Lunak
On Tuesday 03 of December 2013, Reid Kleckner wrote:
 This seems like it has the side effect of trimming leading whitespace from
 the rewritten file, but that's probably fine.

 It's not. The main file does not start with any line markers, so it is 
possible that lines in warnings/errors will be wrong. Please fix this or 
revert the change to the previous one that works.

 On Wed, Nov 27, 2013 at 11:21 PM, Alp Toker a...@nuanti.com wrote:
  Author: alp
  Date: Thu Nov 28 01:21:44 2013
  New Revision: 195910
 
  URL: http://llvm.org/viewvc/llvm-project?rev=195910view=rev
  Log:
  InclusionRewriter: Avoid duplicated BOM check
 
  The lexer already knows its position in the file, so use that instead of
  guessing it might be 3.
 
  Modified:
  cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
 
  Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
  URL:
  http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/Inclus
 ionRewriter.cpp?rev=195910r1=195909r2=195910view=diff
 
  =
 = --- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
  +++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Thu Nov 28
  01:21:44 2013
  @@ -363,15 +363,11 @@ bool InclusionRewriter::Process(FileID F
 if (SM.getFileIDSize(FileId) == 0)
   return false;
 
  -  // The next byte to be copied from the source file
  -  unsigned NextToWrite = 0;
  +  // The next byte to be copied from the source file, which may be
  non-zero if
  +  // the lexer handled a BOM.
  +  unsigned NextToWrite = SM.getFileOffset(RawLex.getSourceLocation());
 int Line = 1; // The current input file line number.
 
  -  // Ignore UTF-8 BOM, otherwise it'd end up somewhere else than the
  start -  // of the resulting file.
  -  if (FromFile.getBuffer().startswith(\xEF\xBB\xBF))
  -NextToWrite = 3;
  -
 Token RawToken;
 RawLex.LexFromRawLexer(RawToken);

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: r195910 - InclusionRewriter: Avoid duplicated BOM check

2013-12-03 Thread Lubos Lunak
On Tuesday 03 of December 2013, Reid Kleckner wrote:
 On Tue, Dec 3, 2013 at 12:01 PM, Lubos Lunak l.lu...@centrum.cz wrote:
  On Tuesday 03 of December 2013, Reid Kleckner wrote:
   This seems like it has the side effect of trimming leading whitespace
 
  from
 
   the rewritten file, but that's probably fine.
 
   It's not. The main file does not start with any line markers, so it is
  possible that lines in warnings/errors will be wrong. Please fix this or
  revert the change to the previous one that works.

 Alternatively, can we emit a #line directive if the line of the first token
 isn't on line 1?

 No, at least not without rewriting SourceManager::isFromMainFile() - 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20131125/094236.html 
.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: r195910 - InclusionRewriter: Avoid duplicated BOM check

2013-12-03 Thread Lubos Lunak
On Tuesday 03 of December 2013, Alp Toker wrote:
 On 03/12/2013 20:01, Lubos Lunak wrote:
  On Tuesday 03 of December 2013, Reid Kleckner wrote:
  This seems like it has the side effect of trimming leading whitespace
  from the rewritten file, but that's probably fine.
 
It's not. The main file does not start with any line markers, so it is
  possible that lines in warnings/errors will be wrong. Please fix this or
  revert the change to the previous one that works.

 Hi Lubos,

 I don't see the problem here. Can you explain, preferably with a test case?

 Never mind, the comment about stripped whitespace is apparently not true.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR9537: Do not warn about unknown pragmas with -Eonly/-M etc.

2013-11-28 Thread Lubos Lunak
On Thursday 28 of November 2013, Richard Smith wrote:
 Some tiny things:

 +  // Ignore also all pragma in all namespaces created
 +  // in Preprocessor::RegisterBuiltinPragmas().

 The English in this (copy-pasted) comment is a bit awkward; can you fix it
 to something like Also ignore all pragmas in [...]

 Please also add to your testcase an instance of a #pragma we don't normally
 understand (#pragma this_pragma_does_not_exist or similar).

 Updated.

 Otherwise, LGTM, thanks!

 On Wed, Nov 27, 2013 at 3:57 PM, Lubos Lunak l.lu...@centrum.cz wrote:
   Hello,
 
   the attached patch should fix PR9537. It is apparently necessary to
  install
  empty pragma handlers for all pragma namespaces that exist.
 
  --
   Lubos Lunak

-- 
 Lubos Lunak
From 6971a5d22562807fc4059bb15190565ca064337f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 23:42:16 +0100
Subject: [PATCH] do not warn about unknown pragmas in modes that do not handle
 them (pr9537)

And refactor to have just one place in code that sets up the empty
pragma handlers.
---
 include/clang/Lex/Preprocessor.h   |  3 +++
 lib/Frontend/FrontendActions.cpp   |  2 +-
 lib/Frontend/PrintPreprocessedOutput.cpp   |  2 +-
 lib/Lex/Pragma.cpp | 11 +++
 lib/Rewrite/Frontend/InclusionRewriter.cpp |  8 +---
 test/Preprocessor/ignore-pragmas.c | 10 ++
 6 files changed, 27 insertions(+), 9 deletions(-)
 create mode 100644 test/Preprocessor/ignore-pragmas.c

diff --git a/include/clang/Lex/Preprocessor.h b/include/clang/Lex/Preprocessor.h
index 2491011..6822424 100644
--- a/include/clang/Lex/Preprocessor.h
+++ b/include/clang/Lex/Preprocessor.h
@@ -643,6 +643,9 @@ public:
 RemovePragmaHandler(StringRef(), Handler);
   }
 
+  /// Install empty handlers for all pragmas (making them ignored).
+  void IgnorePragmas();
+
   /// \brief Add the specified comment handler to the preprocessor.
   void addCommentHandler(CommentHandler *Handler);
 
diff --git a/lib/Frontend/FrontendActions.cpp b/lib/Frontend/FrontendActions.cpp
index a3ab1be..88044f2 100644
--- a/lib/Frontend/FrontendActions.cpp
+++ b/lib/Frontend/FrontendActions.cpp
@@ -485,7 +485,7 @@ void PreprocessOnlyAction::ExecuteAction() {
   Preprocessor PP = getCompilerInstance().getPreprocessor();
 
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   Token Tok;
   // Start parsing the specified input file.
diff --git a/lib/Frontend/PrintPreprocessedOutput.cpp b/lib/Frontend/PrintPreprocessedOutput.cpp
index f3393bf..87fbd04 100644
--- a/lib/Frontend/PrintPreprocessedOutput.cpp
+++ b/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -704,7 +704,7 @@ static int MacroIDCompare(const id_macro_pair *LHS, const id_macro_pair *RHS) {
 
 static void DoPrintMacros(Preprocessor PP, raw_ostream *OS) {
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // -dM mode just scans and ignores all tokens in the files, then dumps out
   // the macro table at the end.
diff --git a/lib/Lex/Pragma.cpp b/lib/Lex/Pragma.cpp
index e4059ee..61bd917 100644
--- a/lib/Lex/Pragma.cpp
+++ b/lib/Lex/Pragma.cpp
@@ -1401,3 +1401,14 @@ void Preprocessor::RegisterBuiltinPragmas() {
 AddPragmaHandler(new PragmaRegionHandler(endregion));
   }
 }
+
+/// Ignore all pragmas, useful for modes such as -Eonly which would otherwise
+/// warn about those pragmas being unknown.
+void Preprocessor::IgnorePragmas() {
+  AddPragmaHandler(new EmptyPragmaHandler());
+  // Also ignore all pragmas in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  AddPragmaHandler(clang, new EmptyPragmaHandler());
+  AddPragmaHandler(STDC, new EmptyPragmaHandler());
+}
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..509e76c 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -517,13 +517,7 @@ void clang::RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS,
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
-  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
-  // (because there's nothing to handle them).
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
-  // Ignore also all pragma in all namespaces created
-  // in Preprocessor::RegisterBuiltinPragmas().
-  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
-  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.
diff --git a/test/Preprocessor/ignore-pragmas.c b/test

Re: [PATCH] Avoid lexer crash with -frewrite-includes

2013-11-28 Thread Lubos Lunak
On Thursday 28 of November 2013, Alp Toker wrote:
 #include rewrite-includes-bom.h#endif /* expanded by -frewrite-includes
 */

 On 27/11/2013 18:24, Lubos Lunak wrote:
As discussed in  [PATCH] PR14795 : -frewrite-includes sometimes
  results in incorrect line number, the following leads to a crash:

 I don't see a crash mentioned in PR14795. Wrong bug?

 That is a reference to the mailing list thread, not to the PR itself.
 Be aware however that with this change, you'll get invalid expansions like:

 #include rewrite-includes-bom.h#endif /* expanded by -frewrite-includes
 */

 Unless this is expected behaviour, you'll need to add special handling
 for end-of-directive in the include rewriter.

 Rather unlikely in practice, but why not, attached.

-- 
 Lubos Lunak
From 85d20f0d25c8fa59241e07cc9d8129184ab01a53 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Thu, 28 Nov 2013 17:03:12 +0100
Subject: [PATCH] ensure newline if last line is #include without trailing \n

---
 lib/Rewrite/Frontend/InclusionRewriter.cpp | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..0effec6 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -259,6 +259,12 @@ void InclusionRewriter::CommentOutDirective(Lexer DirectiveLex,
   OutputContentUpTo(FromFile, NextToWrite,
 SM.getFileOffset(DirectiveToken.getLocation()) + DirectiveToken.getLength(),
 EOL, Line);
+  // Ensure newline before the #endif directive.
+  char LastChar =
+  FromFile.getBufferStart()[SM.getFileOffset(DirectiveToken.getLocation()) +
+DirectiveToken.getLength() - 1];
+  if (LastChar != '\n'  LastChar != '\r')
+OS  EOL;
   OS  #endif /* expanded by -frewrite-includes */  EOL;
 }
 
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR15664 - -frewrite-includes doesn't handle Windows UTF-8 BOM

2013-11-27 Thread Lubos Lunak

 Hello,

 could somebody please review the attached simple patch for PR15664?

 The patch intentionally doesn't do anything fancy except simply removing the 
BOM (which should be unnecessary for UTF-8 anyway). I'm not sure what 
handling other UTF encodings would exactly require, and it's surely better to 
keep the compilation obviously fail for whoever will possibly run into that 
one day and provide a testcase.

-- 
 Lubos Lunak
From 4491c3213d818db8feee5d056bf9ffe87c5692f5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 12:43:30 +0100
Subject: [PATCH] strip UTF-8 BOM in -frewrite-includes (PR#15664)

---
 lib/Rewrite/Frontend/InclusionRewriter.cpp | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..71ceb5f 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -367,6 +367,11 @@ bool InclusionRewriter::Process(FileID FileId,
   unsigned NextToWrite = 0;
   int Line = 1; // The current input file line number.
 
+  // Ignore UTF-8 BOM, otherwise it'd end up somewhere else than the start
+  // of the resulting file.
+  if (FromFile.getBuffer().startswith(\xEF\xBB\xBF))
+NextToWrite = 3;
+
   Token RawToken;
   RawLex.LexFromRawLexer(RawToken);
 
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives

2013-11-27 Thread Lubos Lunak
On Tuesday 30 of July 2013, Eli Friedman wrote:
 On Sun, Jul 28, 2013 at 2:50 AM, Lubos Lunak l.lu...@suse.cz wrote:
  On Monday 01 of July 2013, Eli Friedman wrote:
  On Sun, Jun 30, 2013 at 12:01 AM, Lubos Lunak l.lu...@suse.cz wrote:
 Hello,
  
could somebody please review and commit the atached patch for pr15610
   (it needs the patch for pr15610 applied first in order to apply
   cleanly). Thank you.
  
   Testcase?
 
   Updated.

 This isn't really the right approach; it suppresses the warning when
 the -frewrite-includes flag is used, but not for the output of
 -frewrite-includes, which is what actually matters.

 I disagree (or don't understand what you mean). The -frewrite-includes mode 
is just some auxiliary step that actually has nothing to do with 
preprocessing or compilation, those will be done when the resulting file will 
be compiled. So it should not report or warn about any problem with the file, 
except possible issues related to -frewrite-includes itself, as all those 
reports will be handled when the result is passed to Clang again.

 So if I understand the above correctly as you saying that -Wunused-macros 
should be blocked for -frewrite-includes as well as for the follow-up 
compilation, then this is not right, the warning should be there for the 
actual compilation, just like it is there when compiling the original file 
directly.

 Updated patch that applies to current trunk attached. I've also modified it a 
bit to show that the warnings are blocked for DisableMacroExpansion (since if 
macros are not going to be expanded, they obviously will be unused, so maybe 
it's clearer this way).

 See the thread [PATCH] Correctly check for the main file in the
 presence of line markers.

 I don't find that one relevant (except that with current trunk line markers 
block -Wunused-macros completely, so this is now broken 
with -frewrite-includes, but I'll submit a patch for that).

-- 
 Lubos Lunak
From 18e3e991248d4bd2d4d0360c5a2649106d693b81 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@suse.cz
Date: Sun, 28 Jul 2013 11:32:55 +0200
Subject: [PATCH] do not emit -Wunused-macros warnings in -frewrite-includes
 mode (PR15614)

-frewrite-includes calls PP.SetMacroExpansionOnlyInDirectives() to avoid
macro expansions that are useless in that mode, but this can lead
to -Wunused-macros false positives. As -frewrite-includes does not emit
normal warnings, block -Wunused-macros too.
---
 lib/Lex/PPDirectives.cpp  | 5 +
 test/Frontend/rewrite-includes-warnings.c | 7 ++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/lib/Lex/PPDirectives.cpp b/lib/Lex/PPDirectives.cpp
index 2245086..e80720e 100644
--- a/lib/Lex/PPDirectives.cpp
+++ b/lib/Lex/PPDirectives.cpp
@@ -694,6 +694,9 @@ public:
   pp-DisableMacroExpansion = false;
   }
   ~ResetMacroExpansionHelper() {
+restore();
+  }
+  void restore() {
 PP-DisableMacroExpansion = save;
   }
 private:
@@ -805,6 +808,7 @@ void Preprocessor::HandleDirective(Token Result) {
 
 // C99 6.10.3 - Macro Replacement.
 case tok::pp_define:
+  helper.restore();
   return HandleDefineDirective(Result, ImmediatelyAfterTopLevelIfndef);
 case tok::pp_undef:
   return HandleUndefDirective(Result);
@@ -2137,6 +2141,7 @@ void Preprocessor::HandleDefineDirective(Token DefineTok,
   // If we need warning for not using the macro, add its location in the
   // warn-because-unused-macro set. If it gets used it will be removed from set.
   if (getSourceManager().isInMainFile(MI-getDefinitionLoc()) 
+  !DisableMacroExpansion 
   Diags-getDiagnosticLevel(diag::pp_macro_not_used,
   MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored) {
 MI-setIsWarnIfUnused(true);
diff --git a/test/Frontend/rewrite-includes-warnings.c b/test/Frontend/rewrite-includes-warnings.c
index 1fb98db..c4f38ed 100644
--- a/test/Frontend/rewrite-includes-warnings.c
+++ b/test/Frontend/rewrite-includes-warnings.c
@@ -1,4 +1,9 @@
-// RUN: %clang_cc1 -verify -Wall -Wextra -E -frewrite-includes %s
+// RUN: %clang_cc1 -verify -Wall -Wextra -Wunused-macros -E -frewrite-includes %s
 // expected-no-diagnostics
 
+// PR14831
 #pragma GCC visibility push (default)
+
+// PR15614
+#define FOO 1
+int foo = FOO;
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15610 : -Wunused-macros warns despite line markers

2013-11-27 Thread Lubos Lunak
On Monday 01 of July 2013, Eli Friedman wrote:
 On Sat, Jun 29, 2013 at 11:59 PM, Lubos Lunak l.lu...@suse.cz wrote:
Hello,
 
   could somebody please review and commit the atached patch for pr15610?
  Thank
  you.

 Does this same issue apply to other users of
 Preprocessor::isInPrimaryFile() and/or SourceManager::isFromMainFile()?
  (For example, Preprocessor::HandlePragmaOnce.)  If so, can you please add
 a common helper routine in SourceManager?

 I see you have fixed this meanwhile, but I've noticed that now 
isFromMainFile() is always false for any -frewrite-includes output, since it 
always writes out line markers even for entering the main file. This is not 
necessary and technically it's probably also wrong, so the attached patch 
should fix that. Ok to commit?

-- 
 Lubos Lunak
From f5d9b59510cdc666d134dba8c3b7edf40ff0e698 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 14:43:16 +0100
Subject: [PATCH] do not write line markers for main file in -frewrite-includes
 (pr15610)

Entering any file (according to line markers) makes
SourceManager::isInMainFile() return false, so avoid unnecesary line markers
for the main file.
---
 lib/Rewrite/Frontend/InclusionRewriter.cpp | 3 ++-
 test/Frontend/rewrite-includes.c   | 3 +++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..baab7bf 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -358,7 +358,8 @@ bool InclusionRewriter::Process(FileID FileId,
   StringRef EOL = DetectEOL(FromFile);
 
   // Per the GNU docs: 1 indicates the start of a new file.
-  WriteLineInfo(FileName, 1, FileType, EOL,  1);
+  if (FileId != PP.getPredefinesFileID()  FileId != SM.getMainFileID())
+WriteLineInfo(FileName, 1, FileType, EOL,  1);
 
   if (SM.getFileIDSize(FileId) == 0)
 return false;
diff --git a/test/Frontend/rewrite-includes.c b/test/Frontend/rewrite-includes.c
index 2158dd0..80f6693 100644
--- a/test/Frontend/rewrite-includes.c
+++ b/test/Frontend/rewrite-includes.c
@@ -21,6 +21,9 @@ A(1,2)
 #include rewrite-includes7.h
 #include rewrite-includes8.h
 // ENDCOMPARE
+
+// CHECK-NOT: {{^}}# 1 built-in 1{{$}}
+// CHECK-NOT: {{^}}# 1 {{.*}}rewrite-includes.c 1{{$}}
 // CHECK: {{^}}// STARTCOMPARE{{$}}
 // CHECK-NEXT: {{^}}#define A(a,b) a ## b{{$}}
 // CHECK-NEXT: {{^}}A(1,2){{$}}
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR12463 : Warnings about nonsensical comparisons are disabled if macro expansion is involved

2013-11-27 Thread Lubos Lunak
On Tuesday 30 of July 2013, Eli Friedman wrote:
 On Sun, Jul 28, 2013 at 3:41 AM, Lubos Lunak l.lu...@suse.cz wrote:
  On Monday 01 of July 2013, Eli Friedman wrote:
  On Sat, Jun 29, 2013 at 11:23 PM, Lubos Lunak l.lu...@suse.cz wrote:
Hello,
  
could somebody please review and commit the atached patch for
   pr12463? Thank
   you.
  
   +bool InMacro = LHS.get()-getLocStart().isMacroID() ||
 
  +   RHS.get()-getLocStart().isMacroID();
 
  Why not just check the source location of the operator itself?  It seems
  like we want to diagnose MYMACRO1 == MYMACRO2.
 
   I don't know, because that's not my code. If you look at the patch, this
  is just moved out of the first if(), in order to prevent it from applying
  to all the cases. So maybe it's a good question, but it's not really part
  of this issue.

 Okay, I'll put that aside, then.

 Actually, looking at the end of clang/test/Sema/self-comparison.c , there is 
an explicit check for not diagnosing MACRO1 == MACRO2, referencing 
rdar://problem/8435950 as the reason, whatever that is.

 +!isaStringLiteral(LHSStripped) 
 +!isaObjCEncodeExpr(LHSStripped)) {

 A DeclRefExpr can't be a StringLiteral.

 I guess that must be a left-over from updating the patch when it looked 
bigger than it was because of whitespace changes.

 Why should array1 == array2 and array1 = array2 behave differently
 inside macros?
 With this patch, we won't print the right diagnostic for array1 
 array1 expanded from a macro.

 The difference is that array1 = array2 or array1  array1 is nonsense, no 
matter how I look at it, I can't imagine somebody writing that intentionally. 
However array1 == array2 at least kind of  may make sense, in code that e.g. 
uses macros or #ifdef's (similarly to how some code may end up being 
if(1==1) ).

 But I have no strong opinion on this part, I can make it always or never warn 
when macros are involved if you want (or if that rdar reference above has 
anything to say about it).


 Attached patch is just for string literals, which I hope is without any 
problems or questions, and that's the original reason for my changes. I did 
the arrays part just to keep the whole piece of code consistent, so I can 
follow up with a patch for that, but I don't care much about that part.
 
-- 
 Lubos Lunak
From 602f899c85f3359341e2dd891244dec9a3ba9780 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 17:36:30 +0100
Subject: [PATCH] warn about string literal comparisons even in macros
 (pr12463)

They are unspecified even in macros.
---
 lib/Sema/SemaExpr.cpp | 12 +++-
 test/Sema/exprs.c |  8 
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/lib/Sema/SemaExpr.cpp b/lib/Sema/SemaExpr.cpp
index 84487cc..3f77e83 100644
--- a/lib/Sema/SemaExpr.cpp
+++ b/lib/Sema/SemaExpr.cpp
@@ -7677,22 +7677,24 @@ QualType Sema::CheckCompareOperands(ExprResult LHS, ExprResult RHS,
 
   if (!LHSType-hasFloatingRepresentation() 
   !(LHSType-isBlockPointerType()  IsRelational) 
-  !LHS.get()-getLocStart().isMacroID() 
-  !RHS.get()-getLocStart().isMacroID() 
   ActiveTemplateInstantiations.empty()) {
 // For non-floating point types, check for self-comparisons of the form
 // x == x, x != x, x  x, etc.  These always evaluate to a constant, and
 // often indicate logic errors in the program.
 //
 // NOTE: Don't warn about comparison expressions resulting from macro
-// expansion. Also don't warn about comparisons which are only self
+// expansion, unless they do not make any sense at all.
+// Also don't warn about comparisons which are only self
 // comparisons within a template specialization. The warnings should catch
 // obvious cases in the definition of the template anyways. The idea is to
 // warn when the typed comparison operator will always evaluate to the same
 // result.
+bool InMacro = LHS.get()-getLocStart().isMacroID() ||
+   RHS.get()-getLocStart().isMacroID();
 ValueDecl *DL = getCompareDecl(LHSStripped);
 ValueDecl *DR = getCompareDecl(RHSStripped);
-if (DL  DR  DL == DR  !IsWithinTemplateSpecialization(DL)) {
+if (DL  DR  DL == DR  !IsWithinTemplateSpecialization(DL) 
+!InMacro) {
   DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
0 // self-
(Opc == BO_EQ
@@ -7700,7 +7702,7 @@ QualType Sema::CheckCompareOperands(ExprResult LHS, ExprResult RHS,
   || Opc == BO_GE));
 } else if (DL  DR  LHSType-isArrayType()  RHSType-isArrayType() 
!DL-getType()-isReferenceType() 
-   !DR-getType()-isReferenceType()) {
+   !DR-getType()-isReferenceType()  !InMacro) {
 // what is it always going to eval to?
 char always_evals_to;
 switch(Opc) {
diff --git a/test

[PATCH] Avoid lexer crash with -frewrite-includes

2013-11-27 Thread Lubos Lunak

 As discussed in  [PATCH] PR14795 : -frewrite-includes sometimes results in 
incorrect line number, the following leads to a crash:

$ echo -ne '#if 0\n#endif' a.cpp
$ clang++ -frewrite-includes -E a.cpp

 The attached patch adds a trivial fix avoiding the problem. I'm not quite 
sure why the problem happens, but presumably it has something to do with the 
lexing not being driven by the preprocessor instance (so maybe that one gets 
deleted when reaching EOF?).

-- 
 Lubos Lunak
From 2a79412f4c07af65cc5ff6f187e15da46173e7de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 18:34:05 +0100
Subject: [PATCH] fix Lexer::LexEndOfFile() crash with -frewrite-includes

---
 lib/Lex/Lexer.cpp| 3 ++-
 test/Frontend/rewrite-includes-eof.c | 6 ++
 2 files changed, 8 insertions(+), 1 deletion(-)
 create mode 100644 test/Frontend/rewrite-includes-eof.c

diff --git a/lib/Lex/Lexer.cpp b/lib/Lex/Lexer.cpp
index c071455..009f18a 100644
--- a/lib/Lex/Lexer.cpp
+++ b/lib/Lex/Lexer.cpp
@@ -2460,7 +2460,8 @@ bool Lexer::LexEndOfFile(Token Result, const char *CurPtr) {
 FormTokenWithChars(Result, CurPtr, tok::eod);
 
 // Restore comment saving mode, in case it was disabled for directive.
-resetExtendedTokenMode();
+if (PP)
+  resetExtendedTokenMode();
 return true;  // Have a token.
   }
  
diff --git a/test/Frontend/rewrite-includes-eof.c b/test/Frontend/rewrite-includes-eof.c
new file mode 100644
index 000..d8ec4e9
--- /dev/null
+++ b/test/Frontend/rewrite-includes-eof.c
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -verify -Wall -E -frewrite-includes %s
+// expected-no-diagnostics
+
+#if 0
+// intentionally no \n at the end of this line
+#endif
\ No newline at end of file
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r195877 - strip UTF-8 BOM in -frewrite-includes (PR#15664)

2013-11-27 Thread Lubos Lunak
Author: llunak
Date: Wed Nov 27 15:14:43 2013
New Revision: 195877

URL: http://llvm.org/viewvc/llvm-project?rev=195877view=rev
Log:
strip UTF-8 BOM in -frewrite-includes (PR#15664)


Added:
cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h
cfe/trunk/test/Frontend/rewrite-includes-bom.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=195877r1=195876r2=195877view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Wed Nov 27 15:14:43 
2013
@@ -367,6 +367,11 @@ bool InclusionRewriter::Process(FileID F
   unsigned NextToWrite = 0;
   int Line = 1; // The current input file line number.
 
+  // Ignore UTF-8 BOM, otherwise it'd end up somewhere else than the start
+  // of the resulting file.
+  if (FromFile.getBuffer().startswith(\xEF\xBB\xBF))
+NextToWrite = 3;
+
   Token RawToken;
   RawLex.LexFromRawLexer(RawToken);
 

Added: cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h?rev=195877view=auto
==
--- cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h (added)
+++ cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h Wed Nov 27 15:14:43 
2013
@@ -0,0 +1 @@
+// This file starts with UTF-8 BOM marker.

Added: cfe/trunk/test/Frontend/rewrite-includes-bom.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-bom.c?rev=195877view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-bom.c (added)
+++ cfe/trunk/test/Frontend/rewrite-includes-bom.c Wed Nov 27 15:14:43 2013
@@ -0,0 +1,4 @@
+// RUN: %clang -E -frewrite-includes -I %S/Inputs %s -o - | %clang 
-fsyntax-only -Xclang -verify -x c -
+// expected-no-diagnostics
+
+#include rewrite-includes-bom.h


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15664 - -frewrite-includes doesn't handle Windows UTF-8 BOM

2013-11-27 Thread Lubos Lunak
On Wednesday 27 of November 2013, Reid Kleckner wrote:
 Looks fine, the lexer does this, as well as other places.  Can you add an
 -frewrite-includes test for this?  I think you can rewrite, then run -cc1
 -verify with // expected-no-diagnostics or something like that.

 Oh, did I forget :) ? Updated the patch to the attached version, pushed as 
r195877 and made sure the BOM had made it in.


 On Wed, Nov 27, 2013 at 3:50 AM, Lubos Lunak l.lu...@centrum.cz wrote:
   Hello,
 
   could somebody please review the attached simple patch for PR15664?
 
   The patch intentionally doesn't do anything fancy except simply removing
  the
  BOM (which should be unnecessary for UTF-8 anyway). I'm not sure what
  handling other UTF encodings would exactly require, and it's surely
  better to
  keep the compilation obviously fail for whoever will possibly run into
  that one day and provide a testcase.
 
  --
   Lubos Lunak
 
  ___
  cfe-commits mailing list
  cfe-commits@cs.uiuc.edu
  http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits



-- 
 Lubos Lunak
From 22d7103297a7b42a1cd76661cf881dcdf8f6c5d5 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 12:43:30 +0100
Subject: [PATCH] strip UTF-8 BOM in -frewrite-includes (PR#15664)

---
 lib/Rewrite/Frontend/InclusionRewriter.cpp  | 5 +
 test/Frontend/Inputs/rewrite-includes-bom.h | 1 +
 test/Frontend/rewrite-includes-bom.c| 4 
 3 files changed, 10 insertions(+)
 create mode 100644 test/Frontend/Inputs/rewrite-includes-bom.h
 create mode 100644 test/Frontend/rewrite-includes-bom.c

diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..71ceb5f 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -367,6 +367,11 @@ bool InclusionRewriter::Process(FileID FileId,
   unsigned NextToWrite = 0;
   int Line = 1; // The current input file line number.
 
+  // Ignore UTF-8 BOM, otherwise it'd end up somewhere else than the start
+  // of the resulting file.
+  if (FromFile.getBuffer().startswith(\xEF\xBB\xBF))
+NextToWrite = 3;
+
   Token RawToken;
   RawLex.LexFromRawLexer(RawToken);
 
diff --git a/test/Frontend/Inputs/rewrite-includes-bom.h b/test/Frontend/Inputs/rewrite-includes-bom.h
new file mode 100644
index 000..7ba011f
--- /dev/null
+++ b/test/Frontend/Inputs/rewrite-includes-bom.h
@@ -0,0 +1 @@
+// This file starts with UTF-8 BOM marker.
diff --git a/test/Frontend/rewrite-includes-bom.c b/test/Frontend/rewrite-includes-bom.c
new file mode 100644
index 000..a1aa4c9
--- /dev/null
+++ b/test/Frontend/rewrite-includes-bom.c
@@ -0,0 +1,4 @@
+// RUN: %clang -E -frewrite-includes -I %S/Inputs %s -o - | %clang -fsyntax-only -Xclang -verify -x c -
+// expected-no-diagnostics
+
+#include rewrite-includes-bom.h
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR9537: Do not warn about unknown pragmas with -Eonly/-M etc.

2013-11-27 Thread Lubos Lunak

 Hello,

 the attached patch should fix PR9537. It is apparently necessary to install 
empty pragma handlers for all pragma namespaces that exist.

-- 
 Lubos Lunak
From dd030f1f50e8005be6f7e01ee55ce12b1822ee1b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@centrum.cz
Date: Wed, 27 Nov 2013 23:42:16 +0100
Subject: [PATCH] do not warn about unknown pragmas in modes that do not handle
 them (pr9537)

And refactor to have just one place in code that sets up the empty
pragma handlers.
---
 include/clang/Lex/Preprocessor.h   |  3 +++
 lib/Frontend/FrontendActions.cpp   |  2 +-
 lib/Frontend/PrintPreprocessedOutput.cpp   |  2 +-
 lib/Lex/Pragma.cpp | 11 +++
 lib/Rewrite/Frontend/InclusionRewriter.cpp |  8 +---
 test/Preprocessor/ignore-pragmas.c |  9 +
 6 files changed, 26 insertions(+), 9 deletions(-)
 create mode 100644 test/Preprocessor/ignore-pragmas.c

diff --git a/include/clang/Lex/Preprocessor.h b/include/clang/Lex/Preprocessor.h
index 2491011..6822424 100644
--- a/include/clang/Lex/Preprocessor.h
+++ b/include/clang/Lex/Preprocessor.h
@@ -643,6 +643,9 @@ public:
 RemovePragmaHandler(StringRef(), Handler);
   }
 
+  /// Install empty handlers for all pragmas (making them ignored).
+  void IgnorePragmas();
+
   /// \brief Add the specified comment handler to the preprocessor.
   void addCommentHandler(CommentHandler *Handler);
 
diff --git a/lib/Frontend/FrontendActions.cpp b/lib/Frontend/FrontendActions.cpp
index a3ab1be..88044f2 100644
--- a/lib/Frontend/FrontendActions.cpp
+++ b/lib/Frontend/FrontendActions.cpp
@@ -485,7 +485,7 @@ void PreprocessOnlyAction::ExecuteAction() {
   Preprocessor PP = getCompilerInstance().getPreprocessor();
 
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   Token Tok;
   // Start parsing the specified input file.
diff --git a/lib/Frontend/PrintPreprocessedOutput.cpp b/lib/Frontend/PrintPreprocessedOutput.cpp
index f3393bf..87fbd04 100644
--- a/lib/Frontend/PrintPreprocessedOutput.cpp
+++ b/lib/Frontend/PrintPreprocessedOutput.cpp
@@ -704,7 +704,7 @@ static int MacroIDCompare(const id_macro_pair *LHS, const id_macro_pair *RHS) {
 
 static void DoPrintMacros(Preprocessor PP, raw_ostream *OS) {
   // Ignore unknown pragmas.
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // -dM mode just scans and ignores all tokens in the files, then dumps out
   // the macro table at the end.
diff --git a/lib/Lex/Pragma.cpp b/lib/Lex/Pragma.cpp
index e4059ee..5073a6d 100644
--- a/lib/Lex/Pragma.cpp
+++ b/lib/Lex/Pragma.cpp
@@ -1401,3 +1401,14 @@ void Preprocessor::RegisterBuiltinPragmas() {
 AddPragmaHandler(new PragmaRegionHandler(endregion));
   }
 }
+
+/// Ignore all pragmas, useful for modes such as -Eonly which would otherwise
+/// warn about those pragmas being unknown.
+void Preprocessor::IgnorePragmas() {
+  AddPragmaHandler(new EmptyPragmaHandler());
+  // Ignore also all pragma in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  AddPragmaHandler(clang, new EmptyPragmaHandler());
+  AddPragmaHandler(STDC, new EmptyPragmaHandler());
+}
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index bd4250a..509e76c 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -517,13 +517,7 @@ void clang::RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS,
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
-  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
-  // (because there's nothing to handle them).
-  PP.AddPragmaHandler(new EmptyPragmaHandler());
-  // Ignore also all pragma in all namespaces created
-  // in Preprocessor::RegisterBuiltinPragmas().
-  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
-  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
+  PP.IgnorePragmas();
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.
diff --git a/test/Preprocessor/ignore-pragmas.c b/test/Preprocessor/ignore-pragmas.c
new file mode 100644
index 000..58d51b7
--- /dev/null
+++ b/test/Preprocessor/ignore-pragmas.c
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -E %s -Wall -verify
+// RUN: %clang_cc1 -Eonly %s -Wall -verify
+// RUN: %clang -M -Wall %s -Xclang -verify
+// RUN: %clang -E -frewrite-includes %s -Wall -Xclang -verify
+// RUN: %clang -E -dD -dM %s -Wall -Xclang -verify
+// expected-no-diagnostics
+
+#pragma GCC visibility push (default)
+#pragma weak
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http

Re: r195877 - strip UTF-8 BOM in -frewrite-includes (PR#15664)

2013-11-27 Thread Lubos Lunak
On Wednesday 27 of November 2013, Alp Toker wrote:
 On 27/11/2013 21:14, Lubos Lunak wrote:
  Author: llunak
  Date: Wed Nov 27 15:14:43 2013
  New Revision: 195877
...
 = --- cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h (added)
  +++ cfe/trunk/test/Frontend/Inputs/rewrite-includes-bom.h Wed Nov 27
  15:14:43 2013 @@ -0,0 +1 @@
  +// This file starts with UTF-8 BOM marker.
 
  Added: cfe/trunk/test/Frontend/rewrite-includes-bom.c
  URL:
  http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-inclu
 des-bom.c?rev=195877view=auto
  =
 = --- cfe/trunk/test/Frontend/rewrite-includes-bom.c (added)
  +++ cfe/trunk/test/Frontend/rewrite-includes-bom.c Wed Nov 27 15:14:43
  2013 @@ -0,0 +1,4 @@
  +// RUN: %clang -E -frewrite-includes -I %S/Inputs %s -o - | %clang
  -fsyntax-only -Xclang -verify -x c - +// expected-no-diagnostics
  +
  +#include rewrite-includes-bom.h

 Hi Lubos,

 I don't think it's reasonable to check in this test in its current
 state, given that it passes with or without the BOM. If the invisible
 BOM happens to get removed by automatic encoding transformations in VCS
 or accidental code cleanup, it would give a false sense that the feature
 is working when it could in fact have regressed.

 Actually, most tests do no longer work if they have accidentally their input 
modified to no longer include whatever it is that should find a regression, 
and it's a question how likely it is to happen for any of them.

 Leaving the feature untested until you get round to writing a better
 test, perhaps checking output for presence of BOM with something like
 grep, is preferable for that reason.

 Now only if that were so easy:

 @@ -1,4 +1,5 @@
 -// RUN: %clang -E -frewrite-includes -I %S/Inputs %s -o - | %clang
 -fsyntax-only -Xclang -verify -x c - 
 +// RUN: grep '^\xEF\xBB\xBF'  %S/Inputs/rewrite-includes-bom.h
 +// RUN: %clang_cc1 -E -frewrite-includes -I %S/Inputs %s -o - | %clang_cc1
 -fsyntax-only -verify -x c - | not grep '\xEF\xBB\xBF'

 This test doesn't fail with the BOM removed either. With GNU grep 4.12 that I 
have here, the first grep never matches regardless of whether the BOM is 
there or not (which additionally means that even if the grep worked fine, the 
test still wouldn't fail for a regression).

 Also, the removal of the BOM is already handled by the -fsyntax-only step 
(which fails if the BOM is in the middle of the input), so the last grep 
always checks something where it's never present.

 Also, your commit email address is unreachable. Please update this so we
 can contact you for post-commit review:

 I already had asked for that before the commit. It's just been a long time 
since I last used Subversion.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15664 - -frewrite-includes doesn't handle Windows UTF-8 BOM

2013-11-27 Thread Lubos Lunak
On Thursday 28 of November 2013, Alp Toker wrote:
 While trying to get this test working, I noticed that removing the
 trailing EOF from rewrite-includes-bom.c causes a lexer crash:

 Assertion failed: (PP  Cannot reset token mode without a
 preprocessor), function resetExtendedTokenMode, file
 /Users/alp/Projects/llvm-work/upstream/clang/lib/Lex/Lexer.cpp, line 134.

 Looks like a pre-existing problem though, will file a PR.

 See [PATCH] Avoid lexer crash with -frewrite-includes.

-- 
 Lubos Lunak
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14795 : -frewrite-includes sometimes results in incorrect line number

2013-07-28 Thread Lubos Lunak
On Thursday 25 of July 2013, Eli Friedman wrote:
 On Tue, Jul 23, 2013 at 12:15 AM, Lubos Lunak l.lu...@suse.cz wrote:
  On Tuesday 16 of July 2013, Eli Friedman wrote:
  On Sun, Jul 14, 2013 at 2:16 PM, Lubos Lunak l.lu...@suse.cz wrote:
   On Monday 01 of July 2013, Eli Friedman wrote:
   --- a/lib/Lex/Lexer.cpp
   +++ b/lib/Lex/Lexer.cpp
   @@ -2372,8 +2372,9 @@ bool Lexer::LexEndOfFile(Token Result, const
   char *CurPtr) {
FormTokenWithChars(Result, CurPtr, tok::eod);
  
// Restore comment saving mode, in case it was disabled for
   directive. -resetExtendedTokenMode();
   -return true;  // Have a token.
   +if (PP)
   +  resetExtendedTokenMode();
   +return true; // Have a token.
  }
  
  // If we are in raw mode, return this event as an EOF token.  Let
   the caller
  
   How is this related?
  
I had a crash there without this when I wrote the patch. I don't
   remember the circumstances though and the random testcase I tried
   doesn't trigger it.
 
  Okay.
 
  Please commit without this change.
 
   Actually, LibreOffice is always a good testcase, so I can reproduce the
  crash after all:
...
   So I will include that change too, unless somebody sees a better way of
  avoiding this.

 Can you reduce a testcase?

$ echo -ne '#if 0\n#endif' a.cpp
$ clang++ -frewrite-includes -E a.cpp

(note the lack of the trailing \n)

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives

2013-07-28 Thread Lubos Lunak
On Monday 01 of July 2013, Eli Friedman wrote:
 On Sun, Jun 30, 2013 at 12:01 AM, Lubos Lunak l.lu...@suse.cz wrote:
Hello,
 
   could somebody please review and commit the atached patch for pr15610
  (it needs the patch for pr15610 applied first in order to apply cleanly).
  Thank you.
 
  Testcase?

 Updated.

-- 
 Lubos Lunak
 l.lu...@suse.cz
From c6c972b397f14b261c5350cb45bd94cea6609e7d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@suse.cz
Date: Sun, 28 Jul 2013 11:32:55 +0200
Subject: [PATCH] do not emit -Wunused-macros warnings in -frewrite-includes
 mode (PR15614)

-frewrite-includes calls PP.SetMacroExpansionOnlyInDirectives() to avoid
macro expansions that are useless in that mode, but this can lead
to -Wunused-macros false positives. As -frewrite-includes does not emit
normal warnings, block -Wunused-macros too.
---
 lib/Lex/PPDirectives.cpp  | 3 ++-
 test/Frontend/rewrite-includes-warnings.c | 7 ++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/lib/Lex/PPDirectives.cpp b/lib/Lex/PPDirectives.cpp
index c70019f..06f7283 100644
--- a/lib/Lex/PPDirectives.cpp
+++ b/lib/Lex/PPDirectives.cpp
@@ -2039,7 +2039,8 @@ void Preprocessor::HandleDefineDirective(Token DefineTok,
   // warn-because-unused-macro set. If it gets used it will be removed from set.
   if (isInPrimaryFile()  // don't warn for include'd macros.
   Diags-getDiagnosticLevel(diag::pp_macro_not_used,
-  MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored) {
+  MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored 
+  !MacroExpansionInDirectivesOverride) {
 MI-setIsWarnIfUnused(true);
 WarnUnusedMacroLocs.insert(MI-getDefinitionLoc());
   }
diff --git a/test/Frontend/rewrite-includes-warnings.c b/test/Frontend/rewrite-includes-warnings.c
index 1fb98db..c4f38ed 100644
--- a/test/Frontend/rewrite-includes-warnings.c
+++ b/test/Frontend/rewrite-includes-warnings.c
@@ -1,4 +1,9 @@
-// RUN: %clang_cc1 -verify -Wall -Wextra -E -frewrite-includes %s
+// RUN: %clang_cc1 -verify -Wall -Wextra -Wunused-macros -E -frewrite-includes %s
 // expected-no-diagnostics
 
+// PR14831
 #pragma GCC visibility push (default)
+
+// PR15614
+#define FOO 1
+int foo = FOO;
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR12463 : Warnings about nonsensical comparisons are disabled if macro expansion is involved

2013-07-28 Thread Lubos Lunak
On Monday 01 of July 2013, Eli Friedman wrote:
 On Sat, Jun 29, 2013 at 11:23 PM, Lubos Lunak l.lu...@suse.cz wrote:
   Hello,
 
   could somebody please review and commit the atached patch for pr12463?
  Thank
  you.
 
  +bool InMacro = LHS.get()-getLocStart().isMacroID() ||

 +   RHS.get()-getLocStart().isMacroID();

 Why not just check the source location of the operator itself?  It seems
 like we want to diagnose MYMACRO1 == MYMACRO2.

 I don't know, because that's not my code. If you look at the patch, this is 
just moved out of the first if(), in order to prevent it from applying to all 
the cases. So maybe it's a good question, but it's not really part of this 
issue.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14795 : -frewrite-includes sometimes results in incorrect line number

2013-07-23 Thread Lubos Lunak
On Tuesday 16 of July 2013, Eli Friedman wrote:
 On Sun, Jul 14, 2013 at 2:16 PM, Lubos Lunak l.lu...@suse.cz wrote:
  On Monday 01 of July 2013, Eli Friedman wrote:
  On Sat, Jun 29, 2013 at 11:35 PM, Lubos Lunak l.lu...@suse.cz wrote:
Hello,
  
could somebody please review and commit the atached patch for
   pr14795? Thank
   you.
 
  --- a/lib/Lex/Lexer.cpp
  +++ b/lib/Lex/Lexer.cpp
  @@ -2372,8 +2372,9 @@ bool Lexer::LexEndOfFile(Token Result, const char
  *CurPtr) {
   FormTokenWithChars(Result, CurPtr, tok::eod);
 
   // Restore comment saving mode, in case it was disabled for
  directive. -resetExtendedTokenMode();
  -return true;  // Have a token.
  +if (PP)
  +  resetExtendedTokenMode();
  +return true; // Have a token.
 }
 
 // If we are in raw mode, return this event as an EOF token.  Let the
  caller
 
  How is this related?
 
   I had a crash there without this when I wrote the patch. I don't
  remember the circumstances though and the random testcase I tried doesn't
  trigger it.

 Okay.

 Please commit without this change.

 Actually, LibreOffice is always a good testcase, so I can reproduce the crash 
after all:

#3  0x7f19e5e1e392 in __assert_fail () from /lib64/libc.so.6
#4  0x01fc8e46 in clang::Lexer::resetExtendedTokenMode 
(this=0x7fff35cc4b00) 
at /home/llunak/build/src/llvm/tools/clang/lib/Lex/Lexer.cpp:129
#5  0x01fd11f8 in clang::Lexer::LexEndOfFile (this=0x7fff35cc4b00, 
Result=..., CurPtr=0x75a4c94 ) 
at /home/llunak/build/src/llvm/tools/clang/lib/Lex/Lexer.cpp:2375
#6  0x01fd1743 in clang::Lexer::LexTokenInternal (this=0x7fff35cc4b00, 
Result=...) at /home/llunak/build/src/llvm/tools/clang/lib/Lex/Lexer.cpp:2763
#7  0x01f0c148 in clang::Lexer::Lex (this=0x7fff35cc4b00, Result=...) 
at /home/llunak/build/src/llvm/tools/clang/include/clang/Lex/Lexer.h:145
#8  0x01f0b6a3 in clang::Lexer::LexFromRawLexer (this=0x7fff35cc4b00, 
Result=...) 
at /home/llunak/build/src/llvm/tools/clang/include/clang/Lex/Lexer.h:160
#9  0x02f82cdd in (anonymous namespace)::InclusionRewriter::Process 
(this=0x5be11a0, FileId=..., FileType=clang::SrcMgr::C_ExternCSystem) 
at 
/home/llunak/build/src/llvm/tools/clang/lib/Rewrite/Frontend/InclusionRewriter.cpp:477

 So I will include that change too, unless somebody sees a better way of 
avoiding this.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r186793 - report unused-value warning also for warn_unused types

2013-07-21 Thread Lubos Lunak
Author: llunak
Date: Sun Jul 21 08:15:58 2013
New Revision: 186793

URL: http://llvm.org/viewvc/llvm-project?rev=186793view=rev
Log:
report unused-value warning also for warn_unused types


Modified:
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/test/SemaCXX/warn-unused-value.cpp

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=186793r1=186792r2=186793view=diff
==
--- cfe/trunk/lib/AST/Expr.cpp (original)
+++ cfe/trunk/lib/AST/Expr.cpp Sun Jul 21 08:15:58 2013
@@ -2075,8 +2075,17 @@ bool Expr::isUnusedResultAWarning(const
 return false;
 
   case CXXTemporaryObjectExprClass:
-  case CXXConstructExprClass:
+  case CXXConstructExprClass: {
+if (const CXXRecordDecl *Type = getType()-getAsCXXRecordDecl()) {
+  if (Type-hasAttrWarnUnusedAttr()) {
+WarnE = this;
+Loc = getLocStart();
+R1 = getSourceRange();
+return true;
+  }
+}
 return false;
+  }
 
   case ObjCMessageExprClass: {
 const ObjCMessageExpr *ME = castObjCMessageExpr(this);

Modified: cfe/trunk/test/SemaCXX/warn-unused-value.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-unused-value.cpp?rev=186793r1=186792r2=186793view=diff
==
--- cfe/trunk/test/SemaCXX/warn-unused-value.cpp (original)
+++ cfe/trunk/test/SemaCXX/warn-unused-value.cpp Sun Jul 21 08:15:58 2013
@@ -49,3 +49,23 @@ namespace test2 {
   }
 }
 
+namespace test3 {
+struct Used {
+  Used();
+  Used(int);
+  Used(int, int);
+};
+struct __attribute__((warn_unused)) Unused {
+  Unused();
+  Unused(int);
+  Unused(int, int);
+};
+void f() {
+  Used();
+  Used(1);
+  Used(1, 1);
+  Unused(); // expected-warning {{expression result unused}}
+  Unused(1);// expected-warning {{expression result unused}}
+  Unused(1, 1); // expected-warning {{expression result unused}}
+}
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r186763 - fix sometimes incorrect line numbers in -frewrite-includes mode (pr#14795)

2013-07-20 Thread Lubos Lunak
Author: llunak
Date: Sat Jul 20 09:23:27 2013
New Revision: 186763

URL: http://llvm.org/viewvc/llvm-project?rev=186763view=rev
Log:
fix sometimes incorrect line numbers in -frewrite-includes mode (pr#14795)

Every #include is surrounded by #if 0 in order to comment it out, which adds
lines. That is fixed up right after, but that all can be inside #if part
that is not processed, so fix up also after every end of a conditional part.


Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
cfe/trunk/test/Frontend/rewrite-includes.c

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=186763r1=186762r2=186763view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Sat Jul 20 09:23:27 
2013
@@ -365,7 +365,7 @@ bool InclusionRewriter::Process(FileID F
   RawLex.LexFromRawLexer(RawToken);
   if (RawToken.is(tok::raw_identifier))
 PP.LookUpIdentifierInfo(RawToken);
-  if (RawToken.is(tok::identifier) || RawToken.is(tok::kw_if)) {
+  if (RawToken.getIdentifierInfo() != NULL) {
 switch (RawToken.getIdentifierInfo()-getPPKeywordID()) {
   case tok::pp_include:
   case tok::pp_include_next:
@@ -412,7 +412,9 @@ bool InclusionRewriter::Process(FileID F
 break;
   }
   case tok::pp_if:
-  case tok::pp_elif:
+  case tok::pp_elif: {
+bool elif = (RawToken.getIdentifierInfo()-getPPKeywordID() ==
+ tok::pp_elif);
 // Rewrite special builtin macros to avoid pulling in host details.
 do {
   // Walk over the directive.
@@ -453,8 +455,33 @@ bool InclusionRewriter::Process(FileID F
 OS  */;
   }
 } while (RawToken.isNot(tok::eod));
-
+if (elif) {
+  OutputContentUpTo(FromFile, NextToWrite,
+SM.getFileOffset(RawToken.getLocation()) +
+RawToken.getLength(),
+EOL, Line, /*EnsureNewLine*/ true);
+  WriteLineInfo(FileName, Line, FileType, EOL);
+}
 break;
+  }
+  case tok::pp_endif:
+  case tok::pp_else: {
+// We surround every #include by #if 0 to comment it out, but that
+// changes line numbers. These are fixed up right after that, but
+// the whole #include could be inside a preprocessor conditional
+// that is not processed. So it is necessary to fix the line
+// numbers one the next line after each #else/#endif as well.
+RawLex.SetKeepWhitespaceMode(true);
+do {
+  RawLex.LexFromRawLexer(RawToken);
+} while (RawToken.isNot(tok::eod)  RawToken.isNot(tok::eof));
+OutputContentUpTo(
+FromFile, NextToWrite,
+SM.getFileOffset(RawToken.getLocation()) + 
RawToken.getLength(),
+EOL, Line, /*EnsureNewLine*/ true);
+WriteLineInfo(FileName, Line, FileType, EOL);
+RawLex.SetKeepWhitespaceMode(false);
+  }
   default:
 break;
 }

Modified: cfe/trunk/test/Frontend/rewrite-includes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes.c?rev=186763r1=186762r2=186763view=diff
==
--- cfe/trunk/test/Frontend/rewrite-includes.c (original)
+++ cfe/trunk/test/Frontend/rewrite-includes.c Sat Jul 20 09:23:27 2013
@@ -10,6 +10,7 @@ A(1,2)
 #else
 #include rewrite-includes4.h
 #endif
+  // indented
 #/**/include /**/ rewrite-includes5.h /**/ \
  
 #include rewrite-includes6.h // comment
@@ -48,18 +49,21 @@ A(1,2)
 // CHECK-NEXT: {{^}}included_line3{{$}}
 // CHECK-NEXT: {{^}}# 10 {{.*}}rewrite-includes.c 2{{$}}
 // CHECK-NEXT: {{^}}#else{{$}}
+// CHECK-NEXT: {{^}}# 11 {{.*}}rewrite-includes.c{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include rewrite-includes4.h{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 12 {{.*}}rewrite-includes.c{{$}}
 // CHECK-NEXT: {{^}}#endif{{$}}
+// CHECK-NEXT: {{^}}# 13 {{.*}}rewrite-includes.c{{$}}
+// CHECK-NEXT: {{^}}  // indented{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#/**/include /**/ rewrite-includes5.h /**/ {{\\}}{{$}}
 // CHECK-NEXT: {{^}} {{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 1 {{.*[/\\]Inputs[/\\]}}rewrite-includes5.h 1{{$}}
 // CHECK-NEXT: {{^}}included_line5{{$}}
-// CHECK-NEXT: {{^}}# 15 

r186764 - avoid bogus warnings about unknown pragmas with -frewrite-includes (pr#14831)

2013-07-20 Thread Lubos Lunak
Author: llunak
Date: Sat Jul 20 09:30:01 2013
New Revision: 186764

URL: http://llvm.org/viewvc/llvm-project?rev=186764view=rev
Log:
avoid bogus warnings about unknown pragmas with -frewrite-includes (pr#14831)


Added:
cfe/trunk/test/Frontend/rewrite-includes-warnings.c
Modified:
cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp

Modified: cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp?rev=186764r1=186763r2=186764view=diff
==
--- cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp (original)
+++ cfe/trunk/lib/Rewrite/Frontend/InclusionRewriter.cpp Sat Jul 20 09:30:01 
2013
@@ -16,6 +16,7 @@
 #include clang/Basic/SourceManager.h
 #include clang/Frontend/PreprocessorOutputOptions.h
 #include clang/Lex/HeaderSearch.h
+#include clang/Lex/Pragma.h
 #include clang/Lex/Preprocessor.h
 #include llvm/ADT/SmallString.h
 #include llvm/Support/raw_ostream.h
@@ -503,6 +504,13 @@ void clang::RewriteIncludesInInput(Prepr
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
+  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
+  // (because there's nothing to handle them).
+  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  // Ignore also all pragma in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.

Added: cfe/trunk/test/Frontend/rewrite-includes-warnings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/rewrite-includes-warnings.c?rev=186764view=auto
==
--- cfe/trunk/test/Frontend/rewrite-includes-warnings.c (added)
+++ cfe/trunk/test/Frontend/rewrite-includes-warnings.c Sat Jul 20 09:30:01 2013
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -verify -Wall -Wextra -E -frewrite-includes %s
+// expected-no-diagnostics
+
+#pragma GCC visibility push (default)


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


r186765 - add type attribute warn_unused, for -Wunused-variable warnings (pr#14253)

2013-07-20 Thread Lubos Lunak
Author: llunak
Date: Sat Jul 20 10:05:36 2013
New Revision: 186765

URL: http://llvm.org/viewvc/llvm-project?rev=186765view=rev
Log:
add type attribute warn_unused, for -Wunused-variable warnings (pr#14253)

The functionality is equivalent to the GCC attribute. Variables of tagged
types will be warned about as unused if they are not used in any way
except for possible (even non-trivial) ctors/dtors called. Useful for tagging
classes like std::string (which is not part of this commit).


Added:
cfe/trunk/test/SemaCXX/warn-unused-attribute.cpp
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=186765r1=186764r2=186765view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Sat Jul 20 10:05:36 2013
@@ -749,6 +749,11 @@ def VecReturn : InheritableAttr {
   let Subjects = [CXXRecord];
 }
 
+def WarnUnused : InheritableAttr {
+  let Spellings = [GNUwarn_unused, CXX11gnu, warn_unused];
+  let Subjects = [Record];
+}
+
 def WarnUnusedResult : InheritableAttr {
   let Spellings = [GNUwarn_unused_result,
CXX11clang, warn_unused_result,

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=186765r1=186764r2=186765view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Sat Jul 20 10:05:36 2013
@@ -1320,7 +1320,7 @@ static bool ShouldDiagnoseUnusedDecl(con
 return false;
 
   if (const CXXRecordDecl *RD = dyn_castCXXRecordDecl(Tag)) {
-if (!RD-hasTrivialDestructor())
+if (!RD-hasTrivialDestructor()  !RD-hasAttrWarnUnusedAttr())
   return false;
 
 if (const Expr *Init = VD-getInit()) {
@@ -1330,7 +1330,7 @@ static bool ShouldDiagnoseUnusedDecl(con
 dyn_castCXXConstructExpr(Init);
   if (Construct  !Construct-isElidable()) {
 CXXConstructorDecl *CD = Construct-getConstructor();
-if (!CD-isTrivial())
+if (!CD-isTrivial()  !RD-hasAttrWarnUnusedAttr())
   return false;
   }
 }

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=186765r1=186764r2=186765view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Sat Jul 20 10:05:36 2013
@@ -2668,6 +2668,17 @@ static void handleSentinelAttr(Sema S,
   Attr.getAttributeSpellingListIndex()));
 }
 
+static void handleWarnUnusedAttr(Sema S, Decl *D, const AttributeList Attr) {
+  // Check the attribute arguments.
+  if (!checkAttributeNumArgs(S, Attr, 0))
+return;
+
+  if (RecordDecl *RD = dyn_castRecordDecl(D))
+RD-addAttr(::new (S.Context) WarnUnusedAttr(Attr.getRange(), S.Context));
+  else
+S.Diag(Attr.getLoc(), diag::warn_attribute_ignored)  Attr.getName();
+}
+
 static void handleWarnUnusedResult(Sema S, Decl *D, const AttributeList 
Attr) {
   // check the attribute arguments.
   if (!checkAttributeNumArgs(S, Attr, 0))
@@ -4892,6 +4903,9 @@ static void ProcessInheritableDeclAttr(S
   case AttributeList::AT_TypeVisibility:
 handleVisibilityAttr(S, D, Attr, true);
 break;
+  case AttributeList::AT_WarnUnused:
+handleWarnUnusedAttr(S, D, Attr);
+break;
   case AttributeList::AT_WarnUnusedResult: handleWarnUnusedResult(S, D, Attr);
 break;
   case AttributeList::AT_Weak:handleWeakAttr(S, D, Attr); 
break;

Added: cfe/trunk/test/SemaCXX/warn-unused-attribute.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/warn-unused-attribute.cpp?rev=186765view=auto
==
--- cfe/trunk/test/SemaCXX/warn-unused-attribute.cpp (added)
+++ cfe/trunk/test/SemaCXX/warn-unused-attribute.cpp Sat Jul 20 10:05:36 2013
@@ -0,0 +1,20 @@
+// RUN: %clang_cc1 -fsyntax-only -Wunused-variable -verify %s
+struct __attribute__((warn_unused)) Test
+{
+Test();
+~Test();
+void use();
+};
+
+struct TestNormal
+{
+TestNormal();
+};
+
+int main()
+{
+   Test unused; // expected-warning {{unused variable 'unused'}}
+   Test used;
+   TestNormal normal;
+   used.use();
+}


___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

2013-07-20 Thread Lubos Lunak
On Tuesday 16 of July 2013, Lubos Lunak wrote:
 On Tuesday 16 of July 2013, Lubos Lunak wrote:
  On Tuesday 16 of July 2013, Richard Smith wrote:
   On Tue, Jul 16, 2013 at 12:50 PM, Lubos Lunak l.lu...@suse.cz wrote:
On Tuesday 16 of July 2013, Richard Smith wrote:
 Consider:

 {
   my_lock(my_mutex); // A
   my_lock ml(my_mutex); // B
   my_string(foo); // C
   my_string ms(foo); // D
 }

 We never warn for a class that is in category (1). my_lock would be
 in category (2), so we warn on A but not B. my_string would be in
 category (3), so we warn on both C and D.

 Which of these does the warn_unused attribute model?
   
 It doesn't model anything. It prevents disabling of the
unused-variable warning for whatever type that has the attribute.
  
   So which of the above behaviors do you get? (Or do you get something
   else?)
 
   I think you are talking about something slightly different. This is
  about the (-W)unused-variable warning. So A and C obviously don't apply.

  But since you ask, without looking at the code, presumably
 (-W)unused-result has code similar to unused-variable that also disables
 the warning if the type in question has non-trivial ctor/dtor, so you could
 do a similar modification there to enable the warning for types with
 warn_unused attribute.

 The attached patch adds this functionality for the -Wunused-value warning.

-- 
 Lubos Lunak
 l.lu...@suse.cz
From 0e46fa636b24a9e3e17f99d6d6b440da61b61971 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lubo=C5=A1=20Lu=C5=88=C3=A1k?= l.lu...@suse.cz
Date: Sun, 21 Jul 2013 01:08:27 +0200
Subject: [PATCH] report unused-value warning also for warn_unused types

---
 lib/AST/Expr.cpp   | 13 -
 test/SemaCXX/warn-unused-value.cpp | 20 
 2 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/lib/AST/Expr.cpp b/lib/AST/Expr.cpp
index c4be32e..b3bb3f7 100644
--- a/lib/AST/Expr.cpp
+++ b/lib/AST/Expr.cpp
@@ -2072,8 +2072,19 @@ bool Expr::isUnusedResultAWarning(const Expr *WarnE, SourceLocation Loc,
 return false;
 
   case CXXTemporaryObjectExprClass:
-  case CXXConstructExprClass:
+  case CXXConstructExprClass: {
+QualType Ty = getType();
+if (const TagType *TT = Ty-getAsTagType()) {
+  const TagDecl *Tag = TT-getDecl();
+  if (Tag-hasAttrWarnUnusedAttr()) {
+WarnE = this;
+Loc = getLocStart();
+R1 = getSourceRange();
+return true;
+  }
+}
 return false;
+  }
 
   case ObjCMessageExprClass: {
 const ObjCMessageExpr *ME = castObjCMessageExpr(this);
diff --git a/test/SemaCXX/warn-unused-value.cpp b/test/SemaCXX/warn-unused-value.cpp
index 072ee60..5e43d3e 100644
--- a/test/SemaCXX/warn-unused-value.cpp
+++ b/test/SemaCXX/warn-unused-value.cpp
@@ -49,3 +49,23 @@ namespace test2 {
   }
 }
 
+namespace test3 {
+struct Used {
+  Used();
+  Used(int);
+  Used(int, int);
+};
+struct __attribute__((warn_unused)) Unused {
+  Unused();
+  Unused(int);
+  Unused(int, int);
+};
+void f() {
+  Used();
+  Used(1);
+  Used(1, 1);
+  Unused(); // expected-warning {{expression result unused}}
+  Unused(1);// expected-warning {{expression result unused}}
+  Unused(1, 1); // expected-warning {{expression result unused}}
+}
+}
-- 
1.8.1.4

___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14831: -frewrite-includes incorrect warns about unknown pragmas

2013-07-16 Thread Lubos Lunak
On Tuesday 16 of July 2013, Eli Friedman wrote:
 On Sun, Jul 14, 2013 at 2:35 PM, Lubos Lunak l.lu...@suse.cz wrote:
  On Monday 01 of July 2013, Eli Friedman wrote:
  On Sat, Jun 29, 2013 at 11:49 PM, Lubos Lunak l.lu...@suse.cz wrote:
Hello,
  
could somebody please review and commit the atached patch for
   pr14831? Thank
   you.
 
  Testcase?
 
   Updated patch attached.

 LGTM.

 Please read http://llvm.org/docs/DeveloperPolicy.html and request commit
 access.

 I can do that if it's only about making pushing of my patches less work, but 
I don't think I can fully comply with the requirements. Specifically, I don't 
have the time for the 'Stay Informed' section (it took me two weeks just to 
update a trivial patch) and in fact I intend to unsubscribe again when I have 
no patches pending.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

2013-07-16 Thread Lubos Lunak
On Tuesday 16 of July 2013, David Blaikie wrote:
 I know we'd previously discussed the idea of being able to warn about
 unused variables of non-trivial types - you'd gone so far as to
 suggest the idea of a positive attribute (annotate the classes that
 have side effects, rather than those that don't, since the former
 seems like the exception rather than the rule).

 That may work in an ideal world, but I think in practice the exceptions will 
be what matters. As long as there's a single type missing the annotation 
(which is quite likely, with projects using a number of libraries from 
different providers, etc.), there are likely to be false positives. And I bet 
a number of developers would be rather unhappy to find out that a new 
compiler means they have to somehow work around false warnings about this and 
that 3rd-party library or just disable the warning altogether.

 Moreover, in practice it's quite likely that tagging the most obvious 5% will 
trigger 95% or more of possible (warranted) warnings, as there are only 
certain kinds of classes that are likely to have unused variables. There may 
be a bunch of unused StringRef variables in Clang, but I rather doubt you'll 
find a single unused variable of say FunctionDecl.

 So while the patch is not perfect, I think it's good enough. That said, if 
you do have a better idea, I'm interested.

 I don't suppose that is sufficiently related to this to warrant any
 changes here (we probably want to support this the way GCC does for
 compatibility at least, even if we come up with a more advanced scheme

 There is no the way GCC does. I wrote both of the patches.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

2013-07-16 Thread Lubos Lunak
On Tuesday 16 of July 2013, Richard Smith wrote:
 On Tue, Jul 16, 2013 at 10:45 AM, David Blaikie dblai...@gmail.com wrote:
  I know we'd previously discussed the idea of being able to warn about
  unused variables of non-trivial types - you'd gone so far as to
  suggest the idea of a positive attribute (annotate the classes that
  have side effects, rather than those that don't, since the former
  seems like the exception rather than the rule).

 Right. We usually try to stay on the side of no-false-positives, but in
 this case diligent users would find themselves annotating nearly all
 classes, and that doesn't seem like a good tradeoff.

 I'd rather worry about those that won't be dilligent.

 Also, we identified 
 that there are at least three different kinds of class here:

  1) Those where the ctor and/or the dtor has external, permanent
 side-effects (probably very rare)
  2) Those where the ctor or dtor have external, temporary side-effects, but
 running one then the other is essentially equivalent to running neither
 (for instance, many RAII objects follow this pattern)
  3) Those where the ctor and dtor have no external side-effects

 Consider:

 {
   my_lock(my_mutex); // A
   my_lock ml(my_mutex); // B
   my_string(foo); // C
   my_string ms(foo); // D
 }

 We never warn for a class that is in category (1). my_lock would be in
 category (2), so we warn on A but not B. my_string would be in category
 (3), so we warn on both C and D.

 Which of these does the warn_unused attribute model?

 It doesn't model anything. It prevents disabling of the unused-variable 
warning for whatever type that has the attribute.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

2013-07-16 Thread Lubos Lunak
On Tuesday 16 of July 2013, Richard Smith wrote:
 On Tue, Jul 16, 2013 at 12:50 PM, Lubos Lunak l.lu...@suse.cz wrote:
  On Tuesday 16 of July 2013, Richard Smith wrote:
   Consider:
  
   {
 my_lock(my_mutex); // A
 my_lock ml(my_mutex); // B
 my_string(foo); // C
 my_string ms(foo); // D
   }
  
   We never warn for a class that is in category (1). my_lock would be in
   category (2), so we warn on A but not B. my_string would be in category
   (3), so we warn on both C and D.
  
   Which of these does the warn_unused attribute model?
 
   It doesn't model anything. It prevents disabling of the unused-variable
  warning for whatever type that has the attribute.

 So which of the above behaviors do you get? (Or do you get something else?)

 I think you are talking about something slightly different. This is about the 
(-W)unused-variable warning. So A and C obviously don't apply. B and D will 
cause the warning if the relevant variable has at most trivial ctor/dtor 
called (before my patch), or has at most even non-trivial ctor/dtor called 
but also has the attribute set (added by the patch). That's all.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14253: 'warn_unused' attribute for unused warning for non-POD types

2013-07-16 Thread Lubos Lunak
On Tuesday 16 of July 2013, Lubos Lunak wrote:
 On Tuesday 16 of July 2013, Richard Smith wrote:
  On Tue, Jul 16, 2013 at 12:50 PM, Lubos Lunak l.lu...@suse.cz wrote:
   On Tuesday 16 of July 2013, Richard Smith wrote:
Consider:
   
{
  my_lock(my_mutex); // A
  my_lock ml(my_mutex); // B
  my_string(foo); // C
  my_string ms(foo); // D
}
   
We never warn for a class that is in category (1). my_lock would be
in category (2), so we warn on A but not B. my_string would be in
category (3), so we warn on both C and D.
   
Which of these does the warn_unused attribute model?
  
It doesn't model anything. It prevents disabling of the
   unused-variable warning for whatever type that has the attribute.
 
  So which of the above behaviors do you get? (Or do you get something
  else?)

  I think you are talking about something slightly different. This is about
 the (-W)unused-variable warning. So A and C obviously don't apply.

 But since you ask, without looking at the code, presumably (-W)unused-result 
has code similar to unused-variable that also disables the warning if the 
type in question has non-trivial ctor/dtor, so you could do a similar 
modification there to enable the warning for types with warn_unused 
attribute.

 B and D 
 will cause the warning if the relevant variable has at most trivial
 ctor/dtor called (before my patch), or has at most even non-trivial
 ctor/dtor called but also has the attribute set (added by the patch).
 That's all.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14795 : -frewrite-includes sometimes results in incorrect line number

2013-07-14 Thread Lubos Lunak
On Monday 01 of July 2013, Eli Friedman wrote:
 On Sat, Jun 29, 2013 at 11:35 PM, Lubos Lunak l.lu...@suse.cz wrote:
   Hello,
 
   could somebody please review and commit the atached patch for pr14795?
  Thank
  you.

 --- a/lib/Lex/Lexer.cpp
 +++ b/lib/Lex/Lexer.cpp
 @@ -2372,8 +2372,9 @@ bool Lexer::LexEndOfFile(Token Result, const char
 *CurPtr) {
  FormTokenWithChars(Result, CurPtr, tok::eod);

  // Restore comment saving mode, in case it was disabled for directive.
 -resetExtendedTokenMode();
 -return true;  // Have a token.
 +if (PP)
 +  resetExtendedTokenMode();
 +return true; // Have a token.
}

// If we are in raw mode, return this event as an EOF token.  Let the
 caller

 How is this related?

 I had a crash there without this when I wrote the patch. I don't remember the 
circumstances though and the random testcase I tried doesn't trigger it.

 +// We surround every #include by #if 0 to comment it out, but
 that
 +// changes line numbers. These are fixed up right after that,
 but
 +// the whole #include could be inside a preprocessor
 conditional
 +// that is not processed. So it is necessary to fix the line

 This looks like it puts a line directive after every if/elif/else/endif.
  That not really a problem, I guess, but it would be nice to avoid if
 possible.

 Maybe there can be a way to compute which ones need it (every change from 
ignored to non-ignored block), but that seems like way too much effort for a 
couple of lines.

 Otherwise, looks fine.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [PATCH] PR14831: -frewrite-includes incorrect warns about unknown pragmas

2013-07-14 Thread Lubos Lunak
On Monday 01 of July 2013, Eli Friedman wrote:
 On Sat, Jun 29, 2013 at 11:49 PM, Lubos Lunak l.lu...@suse.cz wrote:
   Hello,
 
   could somebody please review and commit the atached patch for pr14831?
  Thank
  you.

 Testcase?

 Updated patch attached.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 9e4bb3c..3a0a2e9 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -16,6 +16,7 @@
 #include clang/Basic/SourceManager.h
 #include clang/Frontend/PreprocessorOutputOptions.h
 #include clang/Lex/HeaderSearch.h
+#include clang/Lex/Pragma.h
 #include clang/Lex/Preprocessor.h
 #include llvm/ADT/SmallString.h
 #include llvm/Support/raw_ostream.h
@@ -476,6 +477,13 @@ void clang::RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS,
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
+  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
+  // (because there's nothing to handle them).
+  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  // Ignore also all pragma in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.
diff --git a/test/Frontend/rewrite-includes-warnings.c b/test/Frontend/rewrite-includes-warnings.c
new file mode 100644
index 000..1fb98db
--- /dev/null
+++ b/test/Frontend/rewrite-includes-warnings.c
@@ -0,0 +1,4 @@
+// RUN: %clang_cc1 -verify -Wall -Wextra -E -frewrite-includes %s
+// expected-no-diagnostics
+
+#pragma GCC visibility push (default)
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR12463 : Warnings about nonsensical comparisons are disabled if macro expansion is involved

2013-06-30 Thread Lubos Lunak

 Hello,

 could somebody please review and commit the atached patch for pr12463? Thank 
you.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Sema/SemaExpr.cpp b/lib/Sema/SemaExpr.cpp
index 1523563..784b6b2 100644
--- a/lib/Sema/SemaExpr.cpp
+++ b/lib/Sema/SemaExpr.cpp
@@ -7322,48 +7322,55 @@ QualType Sema::CheckCompareOperands(ExprResult LHS, ExprResult RHS,
   diagnoseLogicalNotOnLHSofComparison(*this, LHS, RHS, Loc, OpaqueOpc);
 
   if (!LHSType-hasFloatingRepresentation() 
-  !(LHSType-isBlockPointerType()  IsRelational) 
-  !LHS.get()-getLocStart().isMacroID() 
-  !RHS.get()-getLocStart().isMacroID()) {
+  !(LHSType-isBlockPointerType()  IsRelational)) {
 // For non-floating point types, check for self-comparisons of the form
 // x == x, x != x, x  x, etc.  These always evaluate to a constant, and
 // often indicate logic errors in the program.
 //
-// NOTE: Don't warn about comparison expressions resulting from macro
-// expansion. Also don't warn about comparisons which are only self
+// NOTE: Don't warn about self-comparison expressions resulting from macro
+// expansion, unless they don't make sense at all.
+// Also don't warn about comparisons which are only self
 // comparisons within a template specialization. The warnings should catch
 // obvious cases in the definition of the template anyways. The idea is to
 // warn when the typed comparison operator will always evaluate to the same
 // result.
-if (DeclRefExpr* DRL = dyn_castDeclRefExpr(LHSStripped)) {
+bool InMacro = LHS.get()-getLocStart().isMacroID() ||
+   RHS.get()-getLocStart().isMacroID();
+if (DeclRefExpr *DRL = dyn_castDeclRefExpr(LHSStripped)) {
   if (DeclRefExpr* DRR = dyn_castDeclRefExpr(RHSStripped)) {
+if (isaCastExpr(LHSStripped))
+  LHSStripped = LHSStripped-IgnoreParenCasts();
 if (DRL-getDecl() == DRR-getDecl() 
-!IsWithinTemplateSpecialization(DRL-getDecl())) {
-  DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
-   0 // self-
-   (Opc == BO_EQ
-  || Opc == BO_LE
-  || Opc == BO_GE));
+!IsWithinTemplateSpecialization(DRL-getDecl())  !InMacro 
+!isaStringLiteral(LHSStripped) 
+!isaObjCEncodeExpr(LHSStripped)) {
+  DiagRuntimeBehavior(
+  Loc, 0, PDiag(diag::warn_comparison_always)
+   0 // self-
+   (Opc == BO_EQ || Opc == BO_LE || Opc == BO_GE));
 } else if (LHSType-isArrayType()  RHSType-isArrayType() 
!DRL-getDecl()-getType()-isReferenceType() 
!DRR-getDecl()-getType()-isReferenceType()) {
-// what is it always going to eval to?
-char always_evals_to;
 switch(Opc) {
 case BO_EQ: // e.g. array1 == array2
-  always_evals_to = 0; // false
+  if (!InMacro)
+DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
+ 1 // array
+ 0 /* evaluates to false */);
   break;
 case BO_NE: // e.g. array1 != array2
-  always_evals_to = 1; // true
+  if (!InMacro)
+DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
+ 1 // array
+ 1 /* evaluates to true */);
   break;
-default:
-  // best we can say is 'a constant'
-  always_evals_to = 2; // e.g. array1 = array2
+default: // e.g. array1 = array2
+ // best we can say is 'a constant'
+  DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
+   1 // array
+   2 /* evaluates to constant */);
   break;
 }
-DiagRuntimeBehavior(Loc, 0, PDiag(diag::warn_comparison_always)
- 1 // array
- always_evals_to);
 }
   }
 }
diff --git a/test/Sema/exprs.c b/test/Sema/exprs.c
index 2fb17e4..03d3e7a 100644
--- a/test/Sema/exprs.c
+++ b/test/Sema/exprs.c
@@ -125,6 +125,12 @@ int test12b(const char *X) {
   return sizeof(X == foo); // no-warning
 }
 
+// PR12463
+#define FOO_LITERAL foo
+int test12c(const char *X) {
+  return X == FOO_LITERAL;  // expected-warning {{comparison against a string literal is unspecified (use strncmp instead)}}
+}
+
 // rdar://6719156
 void test13(
 void (^P)()) { // expected-error {{blocks support disabled - compile with -fblocks}}
diff --git a/test/Sema/self-comparison.c b/test

[PATCH] PR14795 : -frewrite-includes sometimes results in incorrect line number

2013-06-30 Thread Lubos Lunak

 Hello,

 could somebody please review and commit the atached patch for pr14795? Thank 
you.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Lex/Lexer.cpp b/lib/Lex/Lexer.cpp
index 9505ccd..0e4e2be 100644
--- a/lib/Lex/Lexer.cpp
+++ b/lib/Lex/Lexer.cpp
@@ -2372,8 +2372,9 @@ bool Lexer::LexEndOfFile(Token Result, const char *CurPtr) {
 FormTokenWithChars(Result, CurPtr, tok::eod);
 
 // Restore comment saving mode, in case it was disabled for directive.
-resetExtendedTokenMode();
-return true;  // Have a token.
+if (PP)
+  resetExtendedTokenMode();
+return true; // Have a token.
   }
  
   // If we are in raw mode, return this event as an EOF token.  Let the caller
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 9e4bb3c..0c3269a 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -365,7 +365,7 @@ bool InclusionRewriter::Process(FileID FileId,
   RawLex.LexFromRawLexer(RawToken);
   if (RawToken.is(tok::raw_identifier))
 PP.LookUpIdentifierInfo(RawToken);
-  if (RawToken.is(tok::identifier) || RawToken.is(tok::kw_if)) {
+  if (RawToken.getIdentifierInfo() != NULL) {
 switch (RawToken.getIdentifierInfo()-getPPKeywordID()) {
   case tok::pp_include:
   case tok::pp_include_next:
@@ -412,7 +412,9 @@ bool InclusionRewriter::Process(FileID FileId,
 break;
   }
   case tok::pp_if:
-  case tok::pp_elif:
+  case tok::pp_elif: {
+bool elif = (RawToken.getIdentifierInfo()-getPPKeywordID() ==
+ tok::pp_elif);
 // Rewrite special builtin macros to avoid pulling in host details.
 do {
   // Walk over the directive.
@@ -453,8 +455,33 @@ bool InclusionRewriter::Process(FileID FileId,
 OS  */;
   }
 } while (RawToken.isNot(tok::eod));
-
+if (elif) {
+  OutputContentUpTo(FromFile, NextToWrite,
+SM.getFileOffset(RawToken.getLocation()) +
+RawToken.getLength(),
+EOL, Line, /*EnsureNewLine*/ true);
+  WriteLineInfo(FileName, Line, FileType, EOL);
+}
 break;
+  }
+  case tok::pp_endif:
+  case tok::pp_else: {
+// We surround every #include by #if 0 to comment it out, but that
+// changes line numbers. These are fixed up right after that, but
+// the whole #include could be inside a preprocessor conditional
+// that is not processed. So it is necessary to fix the line
+// numbers one the next line after each #else/#endif as well.
+RawLex.SetKeepWhitespaceMode(true);
+do {
+  RawLex.LexFromRawLexer(RawToken);
+} while (RawToken.isNot(tok::eod)  RawToken.isNot(tok::eof));
+OutputContentUpTo(
+FromFile, NextToWrite,
+SM.getFileOffset(RawToken.getLocation()) + RawToken.getLength(),
+EOL, Line, /*EnsureNewLine*/ true);
+WriteLineInfo(FileName, Line, FileType, EOL);
+RawLex.SetKeepWhitespaceMode(false);
+  }
   default:
 break;
 }
diff --git a/test/Frontend/rewrite-includes.c b/test/Frontend/rewrite-includes.c
index bf330a6..d6aecb2 100644
--- a/test/Frontend/rewrite-includes.c
+++ b/test/Frontend/rewrite-includes.c
@@ -10,6 +10,7 @@ A(1,2)
 #else
 #include rewrite-includes4.h
 #endif
+  // indented
 #/**/include /**/ rewrite-includes5.h /**/ \
  
 #include rewrite-includes6.h // comment
@@ -48,18 +49,21 @@ A(1,2)
 // CHECK-NEXT: {{^}}included_line3{{$}}
 // CHECK-NEXT: {{^}}# 10 {{.*}}rewrite-includes.c 2{{$}}
 // CHECK-NEXT: {{^}}#else{{$}}
+// CHECK-NEXT: {{^}}# 11 {{.*}}rewrite-includes.c{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include rewrite-includes4.h{{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 12 {{.*}}rewrite-includes.c{{$}}
 // CHECK-NEXT: {{^}}#endif{{$}}
+// CHECK-NEXT: {{^}}# 13 {{.*}}rewrite-includes.c{{$}}
+// CHECK-NEXT: {{^}}  // indented{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#/**/include /**/ rewrite-includes5.h /**/ {{\\}}{{$}}
 // CHECK-NEXT: {{^}} {{$}}
 // CHECK-NEXT: {{^}}#endif /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}# 1 {{.*[/\\]Inputs[/\\]}}rewrite-includes5.h 1{{$}}
 // CHECK-NEXT: {{^}}included_line5{{$}}
-// CHECK-NEXT: {{^}}# 15 {{.*}}rewrite-includes.c 2{{$}}
+// CHECK-NEXT: {{^}}# 16 {{.*}}rewrite-includes.c 2{{$}}
 // CHECK-NEXT: {{^}}#if 0 /* expanded by -frewrite-includes */{{$}}
 // CHECK-NEXT: {{^}}#include rewrite-includes6.h // comment{{$}}
 // CHECK-NEXT

[PATCH] PR14831: -frewrite-includes incorrect warns about unknown pragmas

2013-06-30 Thread Lubos Lunak

 Hello,

 could somebody please review and commit the atached patch for pr14831? Thank 
you.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Rewrite/Frontend/InclusionRewriter.cpp b/lib/Rewrite/Frontend/InclusionRewriter.cpp
index 9e4bb3c..3a0a2e9 100644
--- a/lib/Rewrite/Frontend/InclusionRewriter.cpp
+++ b/lib/Rewrite/Frontend/InclusionRewriter.cpp
@@ -16,6 +16,7 @@
 #include clang/Basic/SourceManager.h
 #include clang/Frontend/PreprocessorOutputOptions.h
 #include clang/Lex/HeaderSearch.h
+#include clang/Lex/Pragma.h
 #include clang/Lex/Preprocessor.h
 #include llvm/ADT/SmallString.h
 #include llvm/Support/raw_ostream.h
@@ -476,6 +477,13 @@ void clang::RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS,
   InclusionRewriter *Rewrite = new InclusionRewriter(PP, *OS,
  Opts.ShowLineMarkers);
   PP.addPPCallbacks(Rewrite);
+  // Ignore all pragmas, otherwise there will be warnings about unknown pragmas
+  // (because there's nothing to handle them).
+  PP.AddPragmaHandler(new EmptyPragmaHandler());
+  // Ignore also all pragma in all namespaces created
+  // in Preprocessor::RegisterBuiltinPragmas().
+  PP.AddPragmaHandler(GCC, new EmptyPragmaHandler());
+  PP.AddPragmaHandler(clang, new EmptyPragmaHandler());
 
   // First let the preprocessor process the entire file and call callbacks.
   // Callbacks will record which #include's were actually performed.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR15610 : -Wunused-macros warns despite line markers

2013-06-30 Thread Lubos Lunak

  Hello,

 could somebody please review and commit the atached patch for pr15610? Thank 
you.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Lex/PPDirectives.cpp b/lib/Lex/PPDirectives.cpp
index 026a7e7..09016a8 100644
--- a/lib/Lex/PPDirectives.cpp
+++ b/lib/Lex/PPDirectives.cpp
@@ -2028,8 +2028,13 @@ void Preprocessor::HandleDefineDirective(Token DefineTok,
   if (isInPrimaryFile()  // don't warn for include'd macros.
   Diags-getDiagnosticLevel(diag::pp_macro_not_used,
   MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored) {
-MI-setIsWarnIfUnused(true);
-WarnUnusedMacroLocs.insert(MI-getDefinitionLoc());
+SourceManager SM = getSourceManager();
+PresumedLoc PLoc = SM.getPresumedLoc(MI-getDefinitionLoc());
+// Do not warn if #line markers say it is not the main file.
+if (PLoc.isValid()  !PLoc.getIncludeLoc().isValid()) {
+  MI-setIsWarnIfUnused(true);
+  WarnUnusedMacroLocs.insert(MI-getDefinitionLoc());
+}
   }
 
   // If the callbacks want to know, tell them about the macro definition.
diff --git a/test/Preprocessor/warn-macro-unused.c b/test/Preprocessor/warn-macro-unused.c
index c33aeb5..30c8800 100644
--- a/test/Preprocessor/warn-macro-unused.c
+++ b/test/Preprocessor/warn-macro-unused.c
@@ -8,3 +8,7 @@ unused
 
 // rdar://9745065
 #undef unused_from_header // no warning
+
+# 1 other.c 1
+#define unused_but_not_main_file // no warning
+
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


[PATCH] PR15614 : -frewrite-includes causes -Wunused-macros false positives

2013-06-30 Thread Lubos Lunak

  Hello,

 could somebody please review and commit the atached patch for pr15610 (it 
needs the patch for pr15610 applied first in order to apply cleanly). Thank 
you.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/lib/Lex/PPDirectives.cpp b/lib/Lex/PPDirectives.cpp
index 09016a8..0164b47 100644
--- a/lib/Lex/PPDirectives.cpp
+++ b/lib/Lex/PPDirectives.cpp
@@ -2027,7 +2027,8 @@ void Preprocessor::HandleDefineDirective(Token DefineTok,
   // warn-because-unused-macro set. If it gets used it will be removed from set.
   if (isInPrimaryFile()  // don't warn for include'd macros.
   Diags-getDiagnosticLevel(diag::pp_macro_not_used,
-  MI-getDefinitionLoc()) != DiagnosticsEngine::Ignored) {
+MI-getDefinitionLoc()) !=
+  DiagnosticsEngine::Ignored  !MacroExpansionInDirectivesOverride) {
 SourceManager SM = getSourceManager();
 PresumedLoc PLoc = SM.getPresumedLoc(MI-getDefinitionLoc());
 // Do not warn if #line markers say it is not the main file.
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [cfe-commits] [PATCH] -rewrite-includes

2012-04-09 Thread Lubos Lunak
On Wednesday 04 of April 2012, Chandler Carruth wrote:
 I'm sorry you feel this way, and got this impression.

 We definitely do want the feature and more contributors. Providing detailed
 code review of new features is actually a very time consuming activity. It
 would be much faster to just reformat the patch ourselves and submit it,
 but that doesn't build up new contributors or give them experience with the
 coding conventions used within the Clang project. It also doesn't scale --
 we can't afford to spend all of our time reformatting other people's
 contributions. Instead, we're trying to teach you *how* to make a
 contribution to the Clang codebase.

 I've done contributions to a number of projects, so I know this, regardless 
of the project it's always a variation of getting it to compile, making a 
patch, posting it for review to wherever the right place is, fixing problems 
that have been pointed out, and repeating until it's either accepted or until 
the effort does not seem worth it. That wasn't the problem, the problem was 
that the 'not worth it' impression rather skyrocketed. A large stick and no 
carrot in sight. That also didn't seem to build up new contributors in this 
case.

 Now, if you're not interested in on-going contributions, that's fair. It is
 absolutely a lot of work to learn and internalize the style and coding
 conventions we use. I'm sorry if I misled you in encouraging you to dive in
 and implement this, and learning the conventions and style used within
 Clang isn't a useful investment of your time.

 If this is how you see it, then indeed you do not view me as a possible 
contributor, because you apparently expect a devotion to the project, which I 
can't and don't want to do. Nor I think it should be necessary. For a project 
where all users are developers, I'd expect it to be quite likely for users to 
just turn up, scratch their itch and disappear again, without really being 
interested in such trivialities like where exactly you must or mustn't put 
your spaces (I myself use 2 coding styles regularly and several more 
occassionally as I touch other projects, and I really have no interest in 
internalizing another style, especially if, honestly, I don't quite like it). 
So yes, this is an unappreciated waste of time.

 That said, this is not even necessary, because there can be an easy technical 
solution, at least for the coding style problem. If I was just given a 
command to format the code the want you want it, I'd just have done it and be 
done with it. Clang seems quite capable at rewriting code and I've noticed 
some mentions of GSoC code reformater task, so just make sure it's usable for 
Clang itself too and it should save a lot of time on both sides.

 A tool won't help with blocking a patch because of other issues, such as the 
reused already existing Clang code (I'd be most probably quite happy to 
improve it in a followup patch in both places), having requirements that even 
core developers don't apparently follow (I can read just a couple of mails on 
this very list to see that new code is not rigidly doxygen-marked 
everywhere), performance improvements that didn't even improve anything, or 
even the absurdity of first asking me to rename a temporary variable away 
from 'I' to something more descriptive and later asking to have a 
reasonably-named variable renamed to 'I', but if you value one perfect patch 
more than a possible contributor and all the followup patches, that's your 
choice.

  session
  would feel like taking over the patch, just go ahead. I don't think
  there's any technical problem with it and I've been using it extensively
  in the last
  few weeks (and I'd be willing to have a look at it if somebody finds an
  actual technical problem in it after all).

 Again, we have a reasonable amount of experience that indicates coding
 conventions, style, and other such factors are critically important to
 long-term maintainability of a large codebase. We consequentially have very
 high standards here.

 I have a reasonable amount of experience indicating that too much is 
sometimes way too much, and I'm not going for another iteration of tedious 
and frustrating manual review of my code for compliancy with a large code 
standard and even larger codebase, sorry.

 To sum up: I think this functionality is good, and eventually someone will
 hopefully have time to pick it up and make the necessary style
 improvements. I can understand if you don't have the time to finish this,
 but until someone can find the time and finish cleaning it up, the patch
 isn't ready to be submitted.

 Too bad it won't make it into 3.1, but at this pace it probably wasn't going 
to anyway.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [cfe-commits] [PATCH] -rewrite-includes

2012-04-04 Thread Lubos Lunak
On Wednesday 04 of April 2012, Matt Beaumont-Gay wrote:
 Looking better.
[list of improvements and improvements skipped]

 You know what, I give up. This is ridiculous and I've had enough.

 Although I have spent quite some time on the patch and really don't like the 
idea of not upstreaming it and keeping it only for me and whoever else would 
be interested, I like even less the idea of going through one more iteration 
of this. I don't think I've ever been treated even close to this when 
submitting a patch to any of the other projects I've sent a patch to. If you 
don't want the feature and a possible contributor, you could have just as 
well said it right at the beginning.

 If somebody with superpowers sufficient to get past this inquisition session 
would feel like taking over the patch, just go ahead. I don't think there's 
any technical problem with it and I've been using it extensively in the last 
few weeks (and I'd be willing to have a look at it if somebody finds an 
actual technical problem in it after all).

 This has been a good example to me of how not to treat patch submissions from 
possible new contributors and I'll make sure to keep it in mind when 
accepting patches for the projects I care for, so thanks at least for the 
lesson.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-31 Thread Lubos Lunak
On Tuesday 27 of March 2012, Matt Beaumont-Gay wrote:
 On Fri, Mar 23, 2012 at 02:08, Lubos Lunak l.lu...@suse.cz wrote:
  On Friday 23 of March 2012, Matt Beaumont-Gay wrote:
  Prefer std::vector -- no reason to use std::list here.
 
   I've meanwhile confirmed that it should be actually std::map for
  noticeably better performance.

 Does a DenseMap (#include llvm/ADT/DenseMap.h) of SourceLocation to
 pairFileID, CharacteristicKind improve performance any further?

 No, because it doesn't compile. Even if I use it properly, the difference is 
neglibible.

   Clang does not even bother to perform repeated inclusion of the same
  file if it somehow detects it's unnecessary, but the avoided
  FileChanged() callback would mean -rewrite-includes would otherwise leave
  some #include directives in the result that would be performed the next
  time.

 Can you use the FileSkipped() callback to make this any more efficient?

 No. If you are asking about the quoted part above, then it's not about 
efficiency, it's about correct/incorrect. If it was a question in general, 
then it's more efficient (and probably also correct, given the action is 
supposed to rewrite includes) to just comment out everything instead of 
figuring out exactly what needs it or not.

 A few new comments, in addition to the general style issues which are
 still unaddressed (doxygen, whitespace, etc):

 I have already converted function/type comments into doxygen comments, and 
there's no point in converting code comments. If you meant to say something 
else with Doxygen comments throughout, you didn't actually say it.

 Updated patch attached.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index 18caca6..b27a717 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -455,6 +455,8 @@ def rewrite_objc : Flag-rewrite-objc,
   HelpTextRewrite ObjC into C (code rewriter example);
 def rewrite_macros : Flag-rewrite-macros,
   HelpTextExpand macros without full preprocessing;
+def rewrite_includes : Flag-rewrite-includes,
+  HelpTextExpand includes without full preprocessing;
 def migrate : Flag-migrate,
   HelpTextMigrate source code;
 }
diff --git a/include/clang/Frontend/FrontendOptions.h b/include/clang/Frontend/FrontendOptions.h
index 49a9ec1..02a0f66 100644
--- a/include/clang/Frontend/FrontendOptions.h
+++ b/include/clang/Frontend/FrontendOptions.h
@@ -44,6 +44,7 @@ namespace frontend {
 PrintPreprocessedInput, /// -E mode.
 PubnamesDump,   /// Print all of the public names in the source.
 RewriteMacros,  /// Expand macros but not #includes.
+RewriteIncludes,/// Expand #includes but not macros.
 RewriteObjC,/// ObjC-C Rewriter.
 RewriteTest,/// Rewriter playground
 RunAnalysis,/// Run one or more source code analyses.
diff --git a/include/clang/Lex/Preprocessor.h b/include/clang/Lex/Preprocessor.h
index 591a449..4b8e1c5 100644
--- a/include/clang/Lex/Preprocessor.h
+++ b/include/clang/Lex/Preprocessor.h
@@ -121,6 +121,13 @@ class Preprocessor : public RefCountedBasePreprocessor {
   /// DisableMacroExpansion - True if macro expansion is disabled.
   bool DisableMacroExpansion : 1;
 
+  /// MacroExpansionInDirectivesOverride - Temporarily disables
+  /// DisableMacroExpansion (i.e. enables expansion) when parsing preprocessor
+  /// directives.
+  bool MacroExpansionInDirectivesOverride : 1;
+
+  class ResetMacroExpansionHelper;
+
   /// \brief Whether we have already loaded macros from the external source.
   mutable bool ReadMacrosFromExternalSource : 1;
 
@@ -631,6 +638,12 @@ public:
 while (Result.getKind() == tok::comment);
   }
 
+  /// Disables macro expansion everywhere except for preprocessor directives.
+  void SetMacroExpansionOnlyInDirectives() {
+DisableMacroExpansion = true;
+MacroExpansionInDirectivesOverride = true;
+  }
+
   /// LookAhead - This peeks ahead N tokens and returns that token without
   /// consuming any tokens.  LookAhead(0) returns the next token that would be
   /// returned by Lex(), LookAhead(1) returns the token after it, etc.  This
diff --git a/include/clang/Rewrite/FrontendActions.h b/include/clang/Rewrite/FrontendActions.h
index 6e9ecac..ea876d9 100644
--- a/include/clang/Rewrite/FrontendActions.h
+++ b/include/clang/Rewrite/FrontendActions.h
@@ -73,6 +73,11 @@ protected:
   void ExecuteAction();
 };
 
+class RewriteIncludesAction : public PreprocessorFrontendAction {
+protected:
+  void ExecuteAction();
+};
+
 }  // end namespace clang
 
 #endif
diff --git a/include/clang/Rewrite/Rewriters.h b/include/clang/Rewrite/Rewriters.h
index 203b9bc..9704fe3 100644
--- a/include/clang/Rewrite/Rewriters.h
+++ b/include/clang/Rewrite/Rewriters.h
@@ -18,6 +18,7 @@
 
 namespace clang {
 class Preprocessor;
+class PreprocessorOutputOptions;
 
 /// RewriteMacrosInInput - Implement -rewrite-macros mode.
 void

Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-23 Thread Lubos Lunak
On Friday 23 of March 2012, Matt Beaumont-Gay wrote:
 A few general comments:

 - No extra whitespace inside delimiters -- if (foo), not if ( foo
 ), and similarly for [] and .
 - Get to know the naming rules in the style guide, and adjust
 capitalization accordingly:
 http://llvm.org/docs/CodingStandards.html#ll_naming

 The thing is, I do know about that page and I tried to follow it, so 
apparently I can't do it on my own (and the fact that the codebase is 
inconsistent on this anyway and I find this style poorly readable is not 
helping). What is the command to automatically format the file to fit your 
requirements?

   std::list FileChange  FileChanges;

 Prefer std::vector -- no reason to use std::list here.

 I've meanwhile confirmed that it should be actually std::map for noticeably 
better performance.

 - Use StringRef in preference to passing a char* and length (e.g. in
 WriteLineInfo):
 http://llvm.org/docs/ProgrammersManual.html#string_apis

 if (type == SrcMgr::C_System)
   OS.write( 3, 2);
 else if (type == SrcMgr::C_ExternCSystem)
   OS.write( 3 4, 4);

 Why OS.write and not operator here?

 Because I reused code from PrintPreprocessedOutput.cpp .

 - Lines should be shorter than 80 columns.

   for (std::list FileChange ::const_iterator it
= FileChanges.begin(), end = FileChanges.end();

 Funny line break here -- prefer breaking after the comma.

 You need to pick your poison. C++ code generally does not fit into 80 columns 
and look nice at the same time.

   OutputContentsUpTo(SM.getFileOffset(DirectiveToken.getLocation())
 + DirectiveToken.getLength(), nextToWrite, FromFile);

 If you have to break a line on one side of a binary operator, prefer
 to break after the operator rather than before.

 In addition to the above, why should I do that? The operator makes it obvious 
why the previous line continues there.

 // It might be beneficial to have a switch that will remove contents of
 lines // that are irrevelant for compile, i.e. comments. Comments are
 actually // the majority of the resulting file and cleaning up such lines
 would // significantly reduce the size of the resulting file without having
 any // effect on any following usage (with the exception of human
 inspection).

 The second sentence here is speculative. Remove the comment entirely,
 or keep the first sentence with FIXME: at the front.

 It is not speculative. There's also nothing broken to fix, it is a suggestion 
for an alternative mode that would have its advantages and disadvantages.

 // clang sometimes optimizes and does not repeatedly include
 some // files even though it should,

 Please elaborate?

 Clang does not even bother to perform repeated inclusion of the same file if 
it somehow detects it's unnecessary, but the avoided FileChanged() callback 
would mean -rewrite-includes would otherwise leave some #include directives 
in the result that would be performed the next time.

   // It would be even faster if the preprocessor could be switched to a
 mode // where it would parse only preprocessor directives and comments,
 nothing // else matters for parsing or processing.

 Technically true, I'm sure, but have you profiled it and found that it
 would actually matter?

 I have done some profiling, yes, and lexing is the majority of time. And 
scanning only for / and \n simply has to be faster. But that is a possible 
improvement for the future and I will not work on this now (although the tone 
of your mail sounds like new potential contributors need to have their zeal 
thoroughly tested by requiring them to submit something that is perfect, in 
case they soon break down from all the nitpicks and run away before making 
any further improvements).

 Updated version attached.

-- 
 Lubos Lunak
 l.lu...@suse.cz
//===--- RewriteIncludes.cpp - Rewrite includes into their expansions -===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===--===//
//
// This code rewrites include invocations into their expansions.  This gives you
// a file with all included files merged into it.
//
//===--===//

#include clang/Rewrite/Rewriters.h
#include clang/Lex/Preprocessor.h
#include clang/Basic/SourceManager.h
#include clang/Frontend/PreprocessorOutputOptions.h
#include llvm/Support/raw_ostream.h

using namespace clang;

namespace {

class IncludeRewriter : public PPCallbacks {
  // Information about which #includes were actually performed,
  // created by preprocessor callbacks.
  struct FileChange {
SourceLocation from;
FileID id;
SrcMgr::CharacteristicKind type;
  };
  Preprocessor PP;
  SourceManager SM;
  raw_ostream OS;
  bool DisableLineMarkers;
  bool UseLineDirective;
  std::map unsigned

Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-19 Thread Lubos Lunak
On Friday 16 of March 2012, Lubos Lunak wrote:
 On Friday 16 of March 2012, Chandler Carruth wrote:
  I've not looked at the patch in detail, but a simple idea: #if 0 block,
  with a comment explaining why.

  That's a very good idea and it seems to work nicely.

  I've also added commenting out #pragma once, and now the patch should be
 hopefully fully ready. I've also done a LibreOffice build again and this
 time there wasn't a single problem.

 I've still found two minor details, and also made it noticeably faster while 
I was at it. But now it's perfect, honest :).

 The latest version is attached. This time it is a patch and separately the 
new source file (to be put in clang/lib/Rewrite), to make review it easier. I 
also do not intend to make further changes until reviewed.

 The changes needed elsewhere are:

- adding the new option and invoking the functionality, trivial duplication 
of -rewrite-macros

- changes in Lexer class to not access the (null) Preprocessor pointer in raw 
mode, which the code normally uses, but temporarily switches to 
ParsingPreprocessorDirective mode (apparently a use case that's not been 
needed yet)

- addition of MacroExpansionInDirectivesOverride flag to Preprocessor, which 
makes it possible to avoid macro expansion everywhere else except in macro 
directives, which reduces the time to process files to less than a half (and 
to less than with plain -E, making icecream's distributed compilation 
actually faster this way). It could be made even faster if the lexer could be 
switched to mode where it would parse only comments and preprocessor 
directives (nothing else matters in this case), and I expect it would be an 
additional boost to distributed compiles, as this step is the bottleneck, but 
maybe later ;).

- and a test, which of course passes. Moreover, as already said, I've 
successfully compiled LibreOffice using this feature.

-- 
 Lubos Lunak
 l.lu...@suse.cz
//===--- RewriteIncludes.cpp - Rewrite includes into their expansions -===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===--===//
//
// This code rewrites include invocations into their expansions.  This gives you
// a file with all included files merged into it.
//
//===--===//

#include clang/Rewrite/Rewriters.h
#include clang/Lex/Preprocessor.h
#include clang/Basic/SourceManager.h
#include clang/Frontend/PreprocessorOutputOptions.h
#include llvm/Support/raw_ostream.h

using namespace clang;

namespace {

class RewriteIncludes : public PPCallbacks {
  // Information about which #includes were actually performed,
  // created by preprocessor callbacks.
  struct FileChange {
SourceLocation from;
FileID id;
SrcMgr::CharacteristicKind type;
  };
  Preprocessor PP;
  SourceManager SM;
  raw_ostream OS;
  bool DisableLineMarkers;
  bool UseLineDirective;
  std::list FileChange  FileChanges;
public:
  RewriteIncludes(Preprocessor pp, raw_ostream os, bool lineMarkers)
 : PP(pp), SM(PP.getSourceManager()),
   OS(os), DisableLineMarkers(lineMarkers) {
// If we're in microsoft mode, use normal #line instead of line markers.
UseLineDirective = PP.getLangOpts().MicrosoftExt;
  }
  bool Process( FileID fileId, SrcMgr::CharacteristicKind type );
private:
  virtual void FileChanged(SourceLocation Loc, FileChangeReason Reason,
   SrcMgr::CharacteristicKind FileType,
   FileID PrevFID);
  virtual void InclusionDirective(SourceLocation HashLoc,
  const Token IncludeTok,
  StringRef FileName,
  bool IsAngled,
  const FileEntry *File,
  SourceLocation EndLoc,
  StringRef SearchPath,
  StringRef RelativePath);
  void WriteLineInfo(const char* filename, int line,
 SrcMgr::CharacteristicKind type,
 const char *Extra = NULL, unsigned ExtraLen = 0);
  void OutputContentsUpTo( unsigned writeEnd, unsigned nextToWrite,
   const llvm::MemoryBuffer* FromFile,
   bool EnsureNewline = false );
  PresumedLoc CommentOutDirective( Lexer DirectivesLex,
const Token StartToken,
unsigned nextToWrite,
const llvm::MemoryBuffer* FromFile );
  const FileChange* FindFileChangeLocation(SourceLocation Loc) const;
  StringRef NextIdentifierName(Lexer RawLex, Token RawToken);
};

}  // end anonymous namespace

void RewriteIncludes::WriteLineInfo(const char* filename, int line

Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-16 Thread Lubos Lunak
On Friday 16 of March 2012, Chandler Carruth wrote:
 On Thu, Mar 15, 2012 at 6:36 AM, Lubos Lunak l.lu...@suse.cz wrote:
   So the only remaing problem should be either finding a way of commenting
  out
  the directives properly or otherwise removing them.

 I've not looked at the patch in detail, but a simple idea: #if 0 block,
 with a comment explaining why.

 That's a very good idea and it seems to work nicely.

 I've also added commenting out #pragma once, and now the patch should be 
hopefully fully ready. I've also done a LibreOffice build again and this time 
there wasn't a single problem.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index d32ea0b..fc9e230 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -446,6 +446,8 @@ def rewrite_objc : Flag-rewrite-objc,
   HelpTextRewrite ObjC into C (code rewriter example);
 def rewrite_macros : Flag-rewrite-macros,
   HelpTextExpand macros without full preprocessing;
+def rewrite_includes : Flag-rewrite-includes,
+  HelpTextExpand includes without full preprocessing;
 def migrate : Flag-migrate,
   HelpTextMigrate source code;
 }
diff --git a/include/clang/Frontend/FrontendOptions.h b/include/clang/Frontend/FrontendOptions.h
index 0ec2f6b..d9b24ba 100644
--- a/include/clang/Frontend/FrontendOptions.h
+++ b/include/clang/Frontend/FrontendOptions.h
@@ -43,6 +43,7 @@ namespace frontend {
 PrintPreamble,  /// Print the preamble of the input file
 PrintPreprocessedInput, /// -E mode.
 RewriteMacros,  /// Expand macros but not #includes.
+RewriteIncludes,/// Expand #includes but not macros.
 RewriteObjC,/// ObjC-C Rewriter.
 RewriteTest,/// Rewriter playground
 RunAnalysis,/// Run one or more source code analyses.
diff --git a/include/clang/Rewrite/FrontendActions.h b/include/clang/Rewrite/FrontendActions.h
index 6e9ecac..ea876d9 100644
--- a/include/clang/Rewrite/FrontendActions.h
+++ b/include/clang/Rewrite/FrontendActions.h
@@ -73,6 +73,11 @@ protected:
   void ExecuteAction();
 };
 
+class RewriteIncludesAction : public PreprocessorFrontendAction {
+protected:
+  void ExecuteAction();
+};
+
 }  // end namespace clang
 
 #endif
diff --git a/include/clang/Rewrite/Rewriters.h b/include/clang/Rewrite/Rewriters.h
index 203b9bc..9704fe3 100644
--- a/include/clang/Rewrite/Rewriters.h
+++ b/include/clang/Rewrite/Rewriters.h
@@ -18,6 +18,7 @@
 
 namespace clang {
 class Preprocessor;
+class PreprocessorOutputOptions;
 
 /// RewriteMacrosInInput - Implement -rewrite-macros mode.
 void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
@@ -25,6 +26,9 @@ void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
 /// DoRewriteTest - A simple test for the TokenRewriter class.
 void DoRewriteTest(Preprocessor PP, raw_ostream *OS);
 
+/// RewriteIncludesInInput - Implement -rewrite-includes mode.
+void RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS, const PreprocessorOutputOptions Opts);
+
 }  // end namespace clang
 
 #endif
diff --git a/lib/Frontend/CompilerInvocation.cpp b/lib/Frontend/CompilerInvocation.cpp
index 13a9897..e8dc20e 100644
--- a/lib/Frontend/CompilerInvocation.cpp
+++ b/lib/Frontend/CompilerInvocation.cpp
@@ -455,6 +455,7 @@ static const char *getActionName(frontend::ActionKind Kind) {
   case frontend::PrintPreamble:  return -print-preamble;
   case frontend::PrintPreprocessedInput: return -E;
   case frontend::RewriteMacros:  return -rewrite-macros;
+  case frontend::RewriteIncludes:return -rewrite-includes;
   case frontend::RewriteObjC:return -rewrite-objc;
   case frontend::RewriteTest:return -rewrite-test;
   case frontend::RunAnalysis:return -analyze;
@@ -1451,6 +1452,8 @@ static InputKind ParseFrontendArgs(FrontendOptions Opts, ArgList Args,
   Opts.ProgramAction = frontend::PrintPreprocessedInput; break;
 case OPT_rewrite_macros:
   Opts.ProgramAction = frontend::RewriteMacros; break;
+case OPT_rewrite_includes:
+  Opts.ProgramAction = frontend::RewriteIncludes; break;
 case OPT_rewrite_objc:
   Opts.ProgramAction = frontend::RewriteObjC; break;
 case OPT_rewrite_test:
diff --git a/lib/FrontendTool/ExecuteCompilerInvocation.cpp b/lib/FrontendTool/ExecuteCompilerInvocation.cpp
index 07d2b8d..49d0bb8 100644
--- a/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ b/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -73,6 +73,7 @@ static FrontendAction *CreateFrontendBaseAction(CompilerInstance CI) {
   case PrintPreamble:  return new PrintPreambleAction();
   case PrintPreprocessedInput: return new PrintPreprocessedAction();
   case RewriteMacros:  return new RewriteMacrosAction();
+  case RewriteIncludes:return new RewriteIncludesAction();
   case RewriteObjC:return new RewriteObjCAction();
   case

Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-15 Thread Lubos Lunak
On Thursday 15 of March 2012, Sebastian Redl wrote:
 On 15.03.2012, at 02:12, Lubos Lunak wrote:
  The code is based on RewriteMacros.cpp and PrintPreprocessedOutput.cpp,
  it more or less works now and I consider it almost ready. The only
  remaining problem I have is commenting out the preprocessor directives -
  I'd like to keep them in the resulting file, similarly to what
  -rewrite-macros does. The problem is that neither /**/ nor // are safe
  for commenting it out in all possible cases, and since this should be
  used for transparent conversion during remote compile, I do not want to
  make assumptions about what the code looks like (e.g. my first trivial
  solution with /**/ failed
  on #include /*MSVC cstdlib */ stdlib.h ). Does somebody know how to
  achieve this? Otherwise I'll probably make it simply erase the
  directives.

 Why isn't // safe?

 It's not in C89.

 It would also generate a warning about a multiline // comment if the 
directive had a trailing \ , which probably is way too obscure to care about, 
but the C89 reason is enough.

 Using /**/ should be actually safe enough if the original code was properly 
split if necessary, but I've already tried that and couldn't get the lexer to 
do it right.

-- 
 Lubos Lunak
 l.lu...@suse.cz
___
cfe-commits mailing list
cfe-commits@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits


Re: [cfe-commits] [PATCH] -rewrite-includes

2012-03-15 Thread Lubos Lunak
On Thursday 15 of March 2012, Lubos Lunak wrote:
  The code is based on RewriteMacros.cpp and PrintPreprocessedOutput.cpp, it
 more or less works now and I consider it almost ready. The only remaining
 problem I have is commenting out the preprocessor directives - I'd like to
 keep them in the resulting file, similarly to what -rewrite-macros does.
 The problem is that neither /**/ nor // are safe for commenting it out in
 all possible cases, and since this should be used for transparent
 conversion during remote compile, I do not want to make assumptions about
 what the code looks like (e.g. my first trivial solution with /**/ failed
 on #include /*MSVC cstdlib */ stdlib.h ). Does somebody know how to
 achieve this? Otherwise I'll probably make it simply erase the directives.

 I've fixed an off-by-one at the end of reading a file, and made it comment 
out all #include directives, because clang optimizes out repeated inclusions 
that would be otherwise performed. Updated patch attached.

 I've successfully rebuilt LibreOffice with the patch, which should be a 
pretty good testcase (especially given that the codebase has reputation for 
initially breaking every single tool used to build it). The only problem I 
had was one system header having #include foo /* multiline\ncomment*/, 
where commenting out with // does not work.

 So the only remaing problem should be either finding a way of commenting out 
the directives properly or otherwise removing them.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index d32ea0b..fc9e230 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -446,6 +446,8 @@ def rewrite_objc : Flag-rewrite-objc,
   HelpTextRewrite ObjC into C (code rewriter example);
 def rewrite_macros : Flag-rewrite-macros,
   HelpTextExpand macros without full preprocessing;
+def rewrite_includes : Flag-rewrite-includes,
+  HelpTextExpand includes without full preprocessing;
 def migrate : Flag-migrate,
   HelpTextMigrate source code;
 }
diff --git a/include/clang/Frontend/FrontendOptions.h b/include/clang/Frontend/FrontendOptions.h
index 0ec2f6b..d9b24ba 100644
--- a/include/clang/Frontend/FrontendOptions.h
+++ b/include/clang/Frontend/FrontendOptions.h
@@ -43,6 +43,7 @@ namespace frontend {
 PrintPreamble,  /// Print the preamble of the input file
 PrintPreprocessedInput, /// -E mode.
 RewriteMacros,  /// Expand macros but not #includes.
+RewriteIncludes,/// Expand #includes but not macros.
 RewriteObjC,/// ObjC-C Rewriter.
 RewriteTest,/// Rewriter playground
 RunAnalysis,/// Run one or more source code analyses.
diff --git a/include/clang/Rewrite/FrontendActions.h b/include/clang/Rewrite/FrontendActions.h
index 6e9ecac..ea876d9 100644
--- a/include/clang/Rewrite/FrontendActions.h
+++ b/include/clang/Rewrite/FrontendActions.h
@@ -73,6 +73,11 @@ protected:
   void ExecuteAction();
 };
 
+class RewriteIncludesAction : public PreprocessorFrontendAction {
+protected:
+  void ExecuteAction();
+};
+
 }  // end namespace clang
 
 #endif
diff --git a/include/clang/Rewrite/Rewriters.h b/include/clang/Rewrite/Rewriters.h
index 203b9bc..9704fe3 100644
--- a/include/clang/Rewrite/Rewriters.h
+++ b/include/clang/Rewrite/Rewriters.h
@@ -18,6 +18,7 @@
 
 namespace clang {
 class Preprocessor;
+class PreprocessorOutputOptions;
 
 /// RewriteMacrosInInput - Implement -rewrite-macros mode.
 void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
@@ -25,6 +26,9 @@ void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
 /// DoRewriteTest - A simple test for the TokenRewriter class.
 void DoRewriteTest(Preprocessor PP, raw_ostream *OS);
 
+/// RewriteIncludesInInput - Implement -rewrite-includes mode.
+void RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS, const PreprocessorOutputOptions Opts);
+
 }  // end namespace clang
 
 #endif
diff --git a/lib/Frontend/CompilerInvocation.cpp b/lib/Frontend/CompilerInvocation.cpp
index 13a9897..e8dc20e 100644
--- a/lib/Frontend/CompilerInvocation.cpp
+++ b/lib/Frontend/CompilerInvocation.cpp
@@ -455,6 +455,7 @@ static const char *getActionName(frontend::ActionKind Kind) {
   case frontend::PrintPreamble:  return -print-preamble;
   case frontend::PrintPreprocessedInput: return -E;
   case frontend::RewriteMacros:  return -rewrite-macros;
+  case frontend::RewriteIncludes:return -rewrite-includes;
   case frontend::RewriteObjC:return -rewrite-objc;
   case frontend::RewriteTest:return -rewrite-test;
   case frontend::RunAnalysis:return -analyze;
@@ -1451,6 +1452,8 @@ static InputKind ParseFrontendArgs(FrontendOptions Opts, ArgList Args,
   Opts.ProgramAction = frontend::PrintPreprocessedInput; break;
 case OPT_rewrite_macros:
   Opts.ProgramAction = frontend::RewriteMacros; break;
+case

Re: [cfe-commits] [PATCH] -Wconversion-null

2012-03-14 Thread Lubos Lunak
On Wednesday 14 of March 2012, David Blaikie wrote:
 On Tue, Mar 13, 2012 at 10:53 PM, Lubos Lunak l.lu...@suse.cz wrote:
   Updated patch attached.

 Great - I have two optional suggestions

 * You can remove the stddef.h include from test/SemaCXX/conversion.cpp

 Done, attached.

 * You could change the NULL usage in conversion-gnunull.cpp to __null
  drop the header to simplify/isolate the test case a bit further.
 (this is, perhaps, debatable - as it doesn't quite test the real use
 case)

 I've left this one as it is. I don't expect the header to break things and 
NULL is what people use in real programs, so in case it actually breaks, it's 
probably better to trigger it here too.

 and one question I can't answer that blocks me from signing
 off/checking this in for you:

 Is the change in lib/Driver/Tools.cpp necessary/correct? I don't fully
 understand what this list is for. Chandler helped me/speculated that
 this is a list of all Clang options that don't exist in GCC 4.2 - but
 if that's the case it's already broken (even by changes I've made -
 such as adding the -Wcovered-switch-default flag which I never added
 to this list). So I'm wondering where this list is tested/validated.
 Hopefully an Apple Clang developer can chime in here  explain this.

 I have no idea, obviously. I only followed usage of another conversion 
option. All I can say is that when removing this change passing
-Wno-conversion-null still disables the warning.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/include/clang/Basic/DiagnosticGroups.td b/include/clang/Basic/DiagnosticGroups.td
index 26dcc40..9baa276 100644
--- a/include/clang/Basic/DiagnosticGroups.td
+++ b/include/clang/Basic/DiagnosticGroups.td
@@ -28,6 +28,7 @@ def Availability : DiagGroupavailability;
 def AutoImport : DiagGroupauto-import;
 def BoolConversions : DiagGroupbool-conversions;
 def IntConversions : DiagGroupint-conversions;
+def ConversionNull : DiagGroupconversion-null;
 def BuiltinRequiresHeader : DiagGroupbuiltin-requires-header;
 def CXXCompat: DiagGroupc++-compat;
 def CastAlign : DiagGroupcast-align;
@@ -282,6 +283,7 @@ def Parentheses : DiagGroupparentheses,
 //   - conversion warnings with constant sources are on by default
 //   - conversion warnings for literals are on by default
 //   - bool-to-pointer conversion warnings are on by default
+//   - __null-to-integer conversion warnings are on by default
 def Conversion : DiagGroupconversion,
[DiagGroupshorten-64-to-32,
 DiagGroupconstant-conversion,
@@ -289,7 +291,8 @@ def Conversion : DiagGroupconversion,
 DiagGroupstring-conversion,
 DiagGroupsign-conversion,
 BoolConversions,
-IntConversions],
+IntConversions,
+ConversionNull],
  DiagCategoryValue Conversion Issue;
 
 def Unused : DiagGroupunused,
@@ -325,6 +328,7 @@ def Extra : DiagGroupextra, [
 def Most : DiagGroupmost, [
 CharSubscript,
 Comment,
+ConversionNull,
 DeleteNonVirtualDtor,
 Format,
 Implicit,
diff --git a/include/clang/Basic/DiagnosticSemaKinds.td b/include/clang/Basic/DiagnosticSemaKinds.td
index d859f37..de9558e 100644
--- a/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/include/clang/Basic/DiagnosticSemaKinds.td
@@ -1733,7 +1733,7 @@ def warn_impcast_bool_to_null_pointer : Warning
 expression, InGroupBoolConversions;
 def warn_impcast_null_pointer_to_integer : Warning
 implicit conversion of NULL constant to integer,
-InGroupDiagGroupconversion, DefaultIgnore;
+InGroupConversionNull;
 def warn_impcast_function_to_bool : Warning
 address of function %q0 will always evaluate to 'true',
 InGroupBoolConversions;
diff --git a/lib/Driver/Tools.cpp b/lib/Driver/Tools.cpp
index 780016a..536897f 100644
--- a/lib/Driver/Tools.cpp
+++ b/lib/Driver/Tools.cpp
@@ -3168,6 +3168,7 @@ void darwin::CC1::RemoveCC1UnsupportedArgs(ArgStringList CmdArgs) const {
 .Case(c++11-narrowing, true)
 .Case(conditional-uninitialized, true)
 .Case(constant-conversion, true)
+.Case(conversion-null, true)
 .Case(CFString-literal, true)
 .Case(constant-logical-operand, true)
 .Case(custom-atomic-properties, true)
diff --git a/test/Analysis/nullptr.cpp b/test/Analysis/nullptr.cpp
index 3f2bac1..b1f4962 100644
--- a/test/Analysis/nullptr.cpp
+++ b/test/Analysis/nullptr.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -analyze -analyzer-checker=core -analyzer-store region -verify %s
+// RUN: %clang_cc1 -std=c++11 -Wno-conversion-null -analyze -analyzer-checker=core -analyzer-store region -verify %s
 
 // test to see if nullptr is detected as a null pointer
 void foo1(void) {
diff --git a/test/SemaCXX/__null.cpp b/test/SemaCXX/__null.cpp
index 1989a45..08d9960 100644
--- a/test/SemaCXX/__null.cpp
+++ b/test

[cfe-commits] [PATCH] -rewrite-includes

2012-03-14 Thread Lubos Lunak

 Hello,

 the attached patch is an attempt at option -rewrite-includes, which is 
similar to -rewrite-macros, but it expands only #include directives.

 The primary motivation is a better functionality of clang together with 
icecream, a distributed compile system (like distcc, only better, 
http://en.opensuse.org/Icecream). Remote compilation works by first 
preprocessing the file and sending the result for actual compilation. This 
difference doesn't matter with gcc, but clang disables some warnings for code 
expanded from macros, and also quotes source code, both of which no longer 
work well in the preprocessed case. So the idea is to add -rewrite-includes, 
which will only merge all included files into the resulting file, without any 
other modifications, and the result will be normally compiled again.

 The code is based on RewriteMacros.cpp and PrintPreprocessedOutput.cpp, it 
more or less works now and I consider it almost ready. The only remaining 
problem I have is commenting out the preprocessor directives - I'd like to 
keep them in the resulting file, similarly to what -rewrite-macros does. The 
problem is that neither /**/ nor // are safe for commenting it out in all 
possible cases, and since this should be used for transparent conversion 
during remote compile, I do not want to make assumptions about what the code 
looks like (e.g. my first trivial solution with /**/ failed 
on #include /*MSVC cstdlib */ stdlib.h ). Does somebody know how to 
achieve this? Otherwise I'll probably make it simply erase the directives.

-- 
 Lubos Lunak
 l.lu...@suse.cz
diff --git a/include/clang/Driver/CC1Options.td b/include/clang/Driver/CC1Options.td
index d32ea0b..fc9e230 100644
--- a/include/clang/Driver/CC1Options.td
+++ b/include/clang/Driver/CC1Options.td
@@ -446,6 +446,8 @@ def rewrite_objc : Flag-rewrite-objc,
   HelpTextRewrite ObjC into C (code rewriter example);
 def rewrite_macros : Flag-rewrite-macros,
   HelpTextExpand macros without full preprocessing;
+def rewrite_includes : Flag-rewrite-includes,
+  HelpTextExpand includes without full preprocessing;
 def migrate : Flag-migrate,
   HelpTextMigrate source code;
 }
diff --git a/include/clang/Frontend/FrontendOptions.h b/include/clang/Frontend/FrontendOptions.h
index 0ec2f6b..d9b24ba 100644
--- a/include/clang/Frontend/FrontendOptions.h
+++ b/include/clang/Frontend/FrontendOptions.h
@@ -43,6 +43,7 @@ namespace frontend {
 PrintPreamble,  /// Print the preamble of the input file
 PrintPreprocessedInput, /// -E mode.
 RewriteMacros,  /// Expand macros but not #includes.
+RewriteIncludes,/// Expand #includes but not macros.
 RewriteObjC,/// ObjC-C Rewriter.
 RewriteTest,/// Rewriter playground
 RunAnalysis,/// Run one or more source code analyses.
diff --git a/include/clang/Rewrite/FrontendActions.h b/include/clang/Rewrite/FrontendActions.h
index 6e9ecac..ea876d9 100644
--- a/include/clang/Rewrite/FrontendActions.h
+++ b/include/clang/Rewrite/FrontendActions.h
@@ -73,6 +73,11 @@ protected:
   void ExecuteAction();
 };
 
+class RewriteIncludesAction : public PreprocessorFrontendAction {
+protected:
+  void ExecuteAction();
+};
+
 }  // end namespace clang
 
 #endif
diff --git a/include/clang/Rewrite/Rewriters.h b/include/clang/Rewrite/Rewriters.h
index 203b9bc..9704fe3 100644
--- a/include/clang/Rewrite/Rewriters.h
+++ b/include/clang/Rewrite/Rewriters.h
@@ -18,6 +18,7 @@
 
 namespace clang {
 class Preprocessor;
+class PreprocessorOutputOptions;
 
 /// RewriteMacrosInInput - Implement -rewrite-macros mode.
 void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
@@ -25,6 +26,9 @@ void RewriteMacrosInInput(Preprocessor PP, raw_ostream *OS);
 /// DoRewriteTest - A simple test for the TokenRewriter class.
 void DoRewriteTest(Preprocessor PP, raw_ostream *OS);
 
+/// RewriteIncludesInInput - Implement -rewrite-includes mode.
+void RewriteIncludesInInput(Preprocessor PP, raw_ostream *OS, const PreprocessorOutputOptions Opts);
+
 }  // end namespace clang
 
 #endif
diff --git a/lib/Frontend/CompilerInvocation.cpp b/lib/Frontend/CompilerInvocation.cpp
index 13a9897..e8dc20e 100644
--- a/lib/Frontend/CompilerInvocation.cpp
+++ b/lib/Frontend/CompilerInvocation.cpp
@@ -455,6 +455,7 @@ static const char *getActionName(frontend::ActionKind Kind) {
   case frontend::PrintPreamble:  return -print-preamble;
   case frontend::PrintPreprocessedInput: return -E;
   case frontend::RewriteMacros:  return -rewrite-macros;
+  case frontend::RewriteIncludes:return -rewrite-includes;
   case frontend::RewriteObjC:return -rewrite-objc;
   case frontend::RewriteTest:return -rewrite-test;
   case frontend::RunAnalysis:return -analyze;
@@ -1451,6 +1452,8 @@ static InputKind ParseFrontendArgs(FrontendOptions Opts, ArgList Args,
   Opts.ProgramAction = frontend::PrintPreprocessedInput; break;
 case

Re: [cfe-commits] [PATCH] -Wconversion-null

2012-03-13 Thread Lubos Lunak
On Tuesday 13 of March 2012, David Blaikie wrote:
 On Tue, Mar 13, 2012 at 3:24 PM, David Blaikie dblai...@gmail.com wrote:
  If you're going to provide a tblgen name for the ConversionNull group,
  perhaps you could define it above the Conversion group  use the
  ConversionNull name (rather than using the conversion-null string
  separately/twice) in Conversion's definition.

 And reuse the ConversionNull named group in DiagnosticSemaKinds.td
 too. The conversion-null string should be written once rather than
 three times.

 Updated patch attached.

  It's probably OK to remove the DefaultIgnore flag for this patch
  too, again to be consistent with GCC (which has this warning on by
  default).

 Hmm, weird - I'm looking at the DiagnosticSemaKinds.td  I'm not sure
 why this warning is actually on by default  your test case is
 passing. (assuming it is)

 It is actually not. I simply copypasted it to a separate file, and I 
ran 'make check', which ran LLVM's checks, and 'make unittest' in clang/, 
which didn't run the tests in tests/ either. The NULL tests pass with the 
updated patch when I run 'make' in clang/tests/.

  One caveat is that this warning is currently a little bit broken in
  Clang. If you initialize an integer of the same size as a pointer, the
  warning will not be provided. i.e. only one warning is produced from:
 
  int i = __null;
  long l = __null;
 
  (__null is the special null value that GNU's stdlib defines NULL to be
   how it detects this case) depending on whether you have a 32 bit or
  64 bit pointer (assuming you have one of those and that int is 32 bits
  and long is 64). That's something to fix at some point...

 I see. I'll leave that as a separate issue.

-- 
 Lubos Lunak
 l.lu...@suse.cz
--- clang/test/SemaCXX/__null.cpp.sav	2011-11-06 14:46:06.0 +0100
+++ clang/test/SemaCXX/__null.cpp	2012-03-14 06:40:33.332259119 +0100
@@ -1,5 +1,5 @@
-// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -fsyntax-only -verify
-// RUN: %clang_cc1 -triple i686-unknown-unknown %s -fsyntax-only -verify
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown %s -Wno-conversion-null -fsyntax-only -verify
+// RUN: %clang_cc1 -triple i686-unknown-unknown %s -Wno-conversion-null -fsyntax-only -verify
 
 void f() {
   int* i = __null;
--- clang/test/SemaCXX/conversion-gnunull.cpp.sav	2012-03-13 21:43:22.493164031 +0100
+++ clang/test/SemaCXX/conversion-gnunull.cpp	2012-03-14 06:43:38.901259331 +0100
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-apple-darwin %s
+
+#include stddef.h
+
+// This file tests -Wconversion-null, a subcategory of -Wconversion
+// which is on by default.
+
+void test3() {
+  int a = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
+  int b;
+  b = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
+// long l = NULL; this should also warn, but currently does not if sizeof(NULL)==sizeof(inttype)
+  int c = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
+  int d;
+  d = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
+}
--- clang/test/SemaCXX/conversion.cpp.sav	2011-11-06 14:46:06.0 +0100
+++ clang/test/SemaCXX/conversion.cpp	2012-03-13 21:43:38.246160011 +0100
@@ -52,12 +52,3 @@ namespace test2 {
 A() : x(10) {} // expected-warning {{implicit truncation from 'int' to bitfield changes value from 10 to 2}}
   };
 }
-
-void test3() {
-  int a = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
-  int b;
-  b = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
-  int c = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
-  int d;
-  d = NULL; // expected-warning {{implicit conversion of NULL constant to integer}}
-}
--- clang/test/Analysis/nullptr.cpp.sav	2012-03-05 11:41:53.0 +0100
+++ clang/test/Analysis/nullptr.cpp	2012-03-14 06:39:49.538259178 +0100
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -std=c++11 -analyze -analyzer-checker=core -analyzer-store region -verify %s
+// RUN: %clang_cc1 -std=c++11 -Wno-conversion-null -analyze -analyzer-checker=core -analyzer-store region -verify %s
 
 // test to see if nullptr is detected as a null pointer
 void foo1(void) {
--- clang/lib/Driver/Tools.cpp.sav	2012-03-07 10:56:50.0 +0100
+++ clang/lib/Driver/Tools.cpp	2012-03-13 21:47:45.876535999 +0100
@@ -3162,6 +3162,7 @@ void darwin::CC1::RemoveCC1UnsupportedAr
 .Case(c++11-narrowing, true)
 .Case(conditional-uninitialized, true)
 .Case(constant-conversion, true)
+.Case(conversion-null, true)
 .Case(CFString-literal, true)
 .Case(constant-logical-operand, true)
 .Case(custom-atomic-properties, true)
--- clang/include/clang/Basic/DiagnosticGroups.td.sav	2012-03-06 22:13:39.0 +0100
+++ clang/include/clang/Basic/DiagnosticGroups.td	2012-03-14 06