There were some frustrating problems with the implementation of

-Wwrite-strings. First and foremost, once the positive form of the flag
was passed, it could never be disabled by passing -Wno-write-strings.
Also, the diagnostic engine couldn't in turn use -Wwrite-strings to
control diagnostics (as GCC does) because it was essentially hijacked to
drive the language semantics.

Fix this by giving CC1 a clean '-fconst-strings' flag to enable
const-qualified strings in C and ObjC compilations. Corresponding
'-fno-const-strings' is also added. Then the driver is taught to
introduce '-fconst-strings' in the CC1 command when '-Wwrite-strings'
dominates.

This entire flag is basically GCC-bug-compatibility driven, so we also
match GCC's bug where '-w' doesn't actually disable -Wwrite-strings. I'm
open to changing this though as it seems insane.

llvm-svn: 130051

1 files changed, 9 insertions, 0 deletions

diff --git a/clang/lib/Driver/Tools.cpp b/clang/lib/Driver/Tools.cpp
index 4e94346de13..436a2a42a42 100644
--- a/clang/lib/Driver/Tools.cpp
+++ b/clang/lib/Driver/Tools.cpp
@@ -1353,6 +1353,15 @@ void Clang::ConstructJob(Compilation &C, const JobAction &JA,
     Args.AddLastArg(CmdArgs, options::OPT_trigraphs);
   }
 
+  // Map the bizarre '-Wwrite-strings' flag to a more sensible
+  // '-fconst-strings'; this better indicates its actual behavior.
+  if (Args.hasFlag(options::OPT_Wwrite_strings, options::OPT_Wno_write_strings,
+                   false)) {
+    // For perfect compatibility with GCC, we do this even in the presence of
+    // '-w'. This flag names something other than a warning for GCC.
+    CmdArgs.push_back("-fconst-strings");
+  }
+
   // Translate GCC's misnamer '-fasm' arguments to '-fgnu-keywords'.
   if (Arg *Asm = Args.getLastArg(options::OPT_fasm, options::OPT_fno_asm)) {
     if (Asm->getOption().matches(options::OPT_fasm))