<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 16, 2012, at 11:00 , Andy Gibbs <<a href="mailto:andyg1001@hotmail.co.uk">andyg1001@hotmail.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Thursday, August 16, 2012 6:28 PM, Jordan Rose wrote:<br><blockquote type="cite">Hm. Now I'm having second thoughts about this:<br><br><blockquote type="cite">fatal_error:<br>      llvm::report_fatal_error(Twine("presence of -verify directives cannot be "<br>                                     "verified during post-processing check of ",<br>                               StringRef(FE ? FE->getName() : "(unknown)")));<br></blockquote><br>This happens if we don't have a SourceManager or Preprocessor available.<br>But what if we really /don't/ have a Preprocessor available?<br></blockquote><br>The best, of course, is that by the time we get to the post-processing<br>check, there are *no* unparsed files.  Thinking about it again, what could<br>be done is this:<br><br>(this is a hybrid between your suggestion and my previous approach)<br><br>Store two lists:<br><br> Map<FileID, FileEntry*> Parsed<br> Map<FileID, Pair<FileEntry*, bool FoundDirectives>> Unparsed<br><br>---When we enter a file from the preprocessor---<br>remove from unparsed set<br>add to parsed set<br><br>---When we get a diagnostic---<br>if (is a macro expansion)<br> ignore [[big culprit this one!]]<br></blockquote><div><br></div><div>Why not look at where the macro is instantiated?</div><div><br></div><br><blockquote type="cite">if (not in parsed set)<br> if (is modules header)<br>   add to parsed set<br> else<br>   run through findDirectives<br>   add to unparsed set, setting FoundDirectives flag appropriately<br><br>---When you check at the end---<br>if (unparsed set not empty)<br> build set of parsed FileEntry pointers<br> iterate through unparsed set:<br>   ignore all files with aliases<br>   fatal error if FoundDirective flag set<br><br><br>This way, SourceManager and Preprocessor instances are not needed at all<br>at the end check.  SourceManager *is* needed for checking diagnostics<br>lists, but this is another thing.  This is the big advantage of this<br>approach: the end check is really freed of its constraints, and<br>becomes a very fast loop (all the data is already gathered).<br><br>The downside, but a small one perhaps?, is that findDirectives may be<br>called more times than necessary.  Analysing the situation: in most<br>cases, a file will be in the parsed set before it produces a diagnostic.<br>Those that aren't are in most cases actually macro expansions and should<br>therefore be ignored.  Those that fall outside that are PCH, modules and<br>-ast-merge tests.  Of these, its the PCH and -ast-merge tests that will<br>call findDirectives on their included files, and therefore be handled<br>less efficiently (potentially) this way.<br></blockquote><div><br></div><div>Once an ID is in Unparsed, you've already run through findDirectives. You could get a few funny issues with aliases here, but I think that's going to be fairly rare (unparsed <i>and</i> aliased <i>and</i> diagnostics from different aliases). So you can just add a check before 'run through findDirectives' to see if it's already been marked as unparsed (and therefore is being externally parsed).</div><div><br></div><br><blockquote type="cite">Now, for findDirectives, we can (I think) get rid of the Preprocessor<br>requirement since the only thing it is really needed for is the LangOpts<br>structure for the Lexer -- the rest is freely available elsewhere.  (And<br>LangOpts can be picked up from BeginSourceFile, so even this shouldn't be<br>a problem.)<br><br>This means we really start to be quite free from the Preprocessor.<br><br>What do you think to this approach?<br></blockquote></div><br><div>I think it works pretty well, but I'd like to see it in code. :-) Apparently my reservations always appear on second reading.</div><div><br></div><div>Thanks for the continued iterations,</div><div>Jordan</div></body></html>