This is an archive of the discontinued LLVM Phabricator instance.

[Coverage] Hide coverage for regions with incorrect end locations (PR39942)
AbandonedPublic

Authored by vsk on Jul 29 2019, 4:45 PM.

Details

Summary

... instead of crashing.

The real bug here is due to clang generating coverage for a conditional
operator expanded from a macro. The location of the end of the
conditional expression is not correct. The actual fix for this requires
chasing down an issue in the lexer/preprocessor.

Diff Detail

Event Timeline

vsk created this revision.Jul 29 2019, 4:45 PM
rnk added a comment.Jul 29 2019, 6:01 PM

I did some digging and I figured out where things go wrong. The issue is the repeated string-izing of the macro argument, the repetition of #func here. This hacky patch seems to fix the issue:

diff --git a/clang/lib/Lex/MacroArgs.cpp b/clang/lib/Lex/MacroArgs.cpp
index 5aa4679fad4..29fd25a43bb 100644
--- a/clang/lib/Lex/MacroArgs.cpp
+++ b/clang/lib/Lex/MacroArgs.cpp
@@ -318,7 +318,7 @@ const Token &MacroArgs::getStringifiedArgument(unsigned ArgNo,
   if (StringifiedArgs.empty())
     StringifiedArgs.resize(getNumMacroArguments(), {});

-  if (StringifiedArgs[ArgNo].isNot(tok::string_literal))
+  //if (StringifiedArgs[ArgNo].isNot(tok::string_literal))
     StringifiedArgs[ArgNo] = StringifyArgument(getUnexpArgument(ArgNo), PP,
                                                /*Charify=*/false,
                                                ExpansionLocStart,

Basically, the second time we process a string-ized macro argument, we hit the cache, which uses the wrong expansion location for the second expansion. I'm going to try cleaning this up and we'll see if the cache is really needed.

vsk abandoned this revision.Jul 30 2019, 10:41 AM

Thanks Reid!